Description

Replaces #12685.

This PR has been started by @griffbrad in #1268 and was desrbibed as follows (with some updates from myself):

It adds a new @wordpress/webpack-config package, which pulls the base webpack config into a package so it can be easily re-used by 3rd-party developers. Once merged, this would allow developers to either depend on the package or run wp-scripts build from @wordpress/scripts to build blocks and extensions using this config.

By having something like this in core, we'd have some simple build tools available out of the box so that block developers don't need to hunt down 3rd-party tools or configure webpack/babel manually. Further, the @wordpress/webpack-config package may also be useful for 3rd-party tool developers (e.g. create-guten-block, gutenblock, etc) who want to better ensure their compatibility with Gutenberg.

Examples of Webpack configs used by plugins

• Gutenberg SlotFill and Filter demos by @ryanwelcher
• Juxtapose Block by @mkaz
• Gutenberg Custom Fields by @youknowriad
• Gutenberg Extensibility Workshop by @youknowriad
• Drop it by @youknowriad
• Tomodomo Block Starter by @chrisvanpatten

How has this been tested?

The first thing to test with this PR is just a normal Gutenberg build because much of the webpack config has been extracted into a package. From what I can tell, everything still builds correctly, tests pass, and Gutenberg appears to function as expected.

Testing block building using wp-scripts is a bit tricky because you're running scripts from unpublished packages only available locally. To make this work, I do the following:

1. Build Gutenberg itself on this feature branch with npm run build.
2. Clone the following example plugin into your plugins folder: https://github.com/griffbrad/wp-scripts-build-block-example-plugin
3. In that plugin's folder, run npm run copy-local-gutenberg-packages && npm i.
4. Run npm run build in the example plugin's folder. The block's code in src/index.js will be built with the output being placed in build.
5. Activate the example plugin and ensure the "WP Scripts Build Tool" block is available and functioning.

These testing instructions copy the built Gutenberg plugin and its packages into the example plugin itself because I've found that using a file ref to traverse back to the parent directory causes NPM to randomly crash and spew non-sense.

Types of changes

New feature

Checklist:

• My code is tested. (Working on a script that does some basic end-to-end testing of the process.)
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

Planned follow-up tasks

• Simpler default for webpack output configuration.
• Docs with examples for modifying the base webpack config when needed. Mostly thinking of this as a "zero configuration" approach, but I can foresee some common tweaks we may want to support.