Core: Bring back common, forum, and admin namespaces in JS

[datitisev]

Related to #1821.

I think it'd be in our best interest to bring back the common, forum and admin namespaces that were removed at some point (I think beta 8).

Pros:

• we don't have to worry about naming files the same in common and forum/admin causing issues (because of flarum.core.compat)
  
  
  
  • also prevents issues when we generate typings - using flarum/forum/Forum instead of flarum/Forum
    
    
  
  
• makes knowing where files are located in core easy when looking at extensions (no need to guess namespace)
• if looking at core, can easily see what the import should be (no need to remove part of it)
• easier to understand from the perspective of a newly starting extension developer (luceos, https://github.com/flarum/core/issues/2085#issuecomment-604285670)

Cons:

• definitely means ALL JS exts will stop working
• @clarkwinkelmann thinks it'd be more readable, likes bundling & common

What we could do is allow both ways- keep the current structure without the stack in flarum.core.compat BUT also allow including the stack when typing code (stripped on build). This could cause confusion, however.

If I missed any pro/con, please comment so.

[luceos]

It's also easier to understand from the perspective of a newly starting extension developer.

[tankerkiller125]

I feel like the majority of JS extensions will probably break in the rewrite anyways. I think the benefits far outweigh the cons here. Just making it easier to understand for new extension developers I think alone outweighs the cons.

[clarkwinkelmann]

We currently accept using the /admin and /forum imports when using @ imports https://github.com/flarum/flarum-webpack-config/blob/master/index.js#L55

We can add that as well as /common support to the "old-style" section so that developers can prepare their extensions for the upcoming change.

[datitisev]

@clarkwinkelmann I don't think there's a single extension that uses @flarum/core imports - mainly because core exports barely anything and it's not documented in the slightest.

I didn't even know we had JS extenders 🤷‍♂

[askvortsov1]

I'm generally in the 'explicit is better than implicit' camp, and I think this makes things clearer. I'm in favor.

[luceos]

@franzliedke could you share your thoughts on this one too 🙏

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum.
In any case, thanks for taking an interest in this software and contributing by opening the issue in the first place!

[datitisev]

Still relevant. We're probably doing this.

[clarkwinkelmann]

Discussed in today's meeting: if we want to refactor compat to include the namespace (and allow identical names in common and forum/admin), we should do both that and this issue subject at the same time so extensions won't need to re-compile.

Doing so requires completely removing the ability to include without namespace I think.

[askvortsov1]

So that would leave us without a BC layer?

[datitisev]

@clarkwinkelmann I think I maybe didn't explain things correctly during the meeting.

If we want to include the namespaces without immediately requiring extensions to update their code, we need a BC layer.

If we don't want to include the namespaces just yet but allow extension developers to use them in imports, we need the webpack PR.

You can't really have both this issue & the webpack PR because the webpack PR gets rid of the namespaces and this issue would add them to compat.js - making any import not work.

If the namespace is added to the compat imports without a BC layer the extensions will need to update their code.

[askvortsov1]

Which webpack PR in particular are we talking about?

And for BC layer, do you mean duplicating the content of the compat files so that every item has 2 keys? Would that increase bundle size?

[datitisev]

I'm talking about https://github.com/flarum/flarum-webpack-config/pull/7.

A BC layer here, with the current system, would mean duplicating all the keys in the object, yes. That would increase bundle size, but not by a noticeable amount, I would think.

[askvortsov1]

So in your opinion, we should go for this issue with a BC layer and not the webpack PR?

[datitisev]

Yes, because both instances require extension developers to update their imports at some point. The webpack PR would be a temporary solution that is mainly to allow typings (once I get around to creating those) to work anyway. Once the namespaces are added to compat.js the extension developer would have to update & rebuild their dist again.

[askvortsov1]

Lets do that then.