Build: Introduce the common build folder to be used by all modules

[gziolo]

Description

This PR changes the way we manage build folders. Instead of having a subfolder for each module, the changes proposed cause to have one common build folder. It should make it easier to reason which folders contain the source code and which are external ones. This will also make easier to exclude build folders from search results in your IDEs.

As part of this PR I also extracted a11y and dom-ready to be served as external packages. This allowed to move domReady call from editPost module to client-assets.php file as suggested by @aduth in #6448 (comment):

Should it be up to the editor to decide the specific time it should be initialized? Or should the prerequisite of the initialization be considered by that which is initializing it (thinking outside the specific "WP + Plugins" context).

Having dom-ready and a11y extracted was also discussed in #6526 (comment):

I expect for compatibility's sake we'd not want to remove any of the existing scripts, though my preference moving forward would be that there is a corresponding script handle for every single NPM package under the WordPress scope.

How has this been tested?

Manually made sure there are no regressions.

All commands should work as before, in particular, the following must be double checked:

• npm test
• npm run build
• npm run dev
• npm run package-plugin

Screenshots

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[youknowriad]

Seems like a good improvement to me, I wonder why we didn't do this in the first place. Any idea @aduth ?

[gziolo]

I'm not sure how it aligns with the plan to expose Gutenberg modules to npm to make it possible to use them with other projects. In particular, the changes I proposed to have one build folder, might not work well in the scenario where we want to publish every such module separately to npm. It all depends which direction we are going to pick - continue to move all modules to WordPress/packages or the other way around.

[aduth]

Related: #6087 (cc @kanishkdudeja)

[aduth]

I don't have a strong opinion one way or the other, but yes, a build folder in each is in line with treating them as independent modules.

[gziolo]

It looks like a similar approach to what @kanishkdudeja did. It might be also the case that there should be a different version of build files exposed for Gutenberg than for npm modules. For example we will have to expose source files for RN because web ignores ‘*.native.js’ overrides.

[youknowriad]

I think it's an nice devx improvement for now. Let's reconsider once we tackle publishing packages as npm dependencies later, as not certain how that would work (packages repository or this one)

[aduth]

Why are we calling default ? Is this an ES2015 module issue ? This should be called on as wp.domReady( fn );. Seems like a bug.

[gziolo]

I think it's the issue with how Webpack is configured. wp.domReady is an object with the current setup:

[aduth]

I dug into this a bit, and it's trickier than it appears on the surface.

This is what Webpack's output.libraryExport configuration is meant to support: Setting a specific property as the value assigned on the library target (window).

However, we have mixed needs: For something like wp.editor or wp.i18n, we want named exports to be respected, and assigned as nested properties within. For dom-ready though, the default export function should be assigned as wp.domReady.

In my head, it's as though we want libraryExport: 'default' when there are no other named exports, otherwise using the default _entry_return_.

So far as implementation, we might need to get our hands dirty with a custom Webpack plugin to achieve this. It probably needs to extend (whether via classical inheritance or just dynamically instantiating during apply, I'm uncertain) Webpack's ExportPropertyMainTemplatePlugin.js. Where I started having trouble was determining the exports of a module to decide what to assign as libraryExport.

[aduth]

Alternative: have separate output configurations for specific edge-case modules like dom-ready, where we can assign libraryExport: 'default'. This too is not made very simple in an all-in-one Webpack configuration like we have.

Alternative alternative: Don't allow default exports on packages.

Alternative alternative alternative: Use CommonJS module.exports instead of export default from the packages implementation.

[youknowriad]

Alternative Alternative Alternative, assign the globals manually in "enqueues" importing things from the regular built modules :)

[aduth]

Moving task to #6748 for further discussion.