Enable extending webpack.config.js in packages/scripts/

[mor10]

When using @wordpress/scripts, you can replace the existing webpack.config.js file with your own. It would be great if instead of having to build a full webpack config manually there was a way of extending the existing config to add a new module or similar. As an example, @svgr/webpack is useful in the context of blocks but using it means rewriting the entire webpack.config.js file.

[swissspidy]

You can totally extend the default config. Gutenberg does it already.

I also did it yesterday in a plugin: ampproject/amp-wp#2000

[mor10]

Hmmmmmm. I must be doing something wrong then. Or maybe we're not talking about the same thing.

[mor10]

@swissspidy can you point me at a basic example of extending the Webpack config with a single module?

[youknowriad]

Here's how you import the config https://github.com/WordPress/gutenberg/blob/master/webpack.config.js#L16 and you can see a few lines after how it's reused.

I hope this helps.

[youknowriad]

Can I ask why using wp-scripts build without extending is enough or not? Asking to see if there are common patterns we can ship by default in the scripts module.

[swissspidy]

For me the most annoying part is the default entry configuration with src and build. This might work well if you just have a single block in your plugin, but not when it is a bit more complex. Also, as Morten mentioned, adding more modules is often needed. But I think it is fine to just extend the config at this point. It's really straightforward.

[youknowriad]

@swissspidy What if we mimic parcel's api where we could do:

wp-scripts src/file1.js src/file2.js -o dist

This would produce two scripts based on these two entry points?

cc @gziolo

[gziolo]

@swissspidy can you point me at a basic example of extending the Webpack config with a single module?

I see this line imports default config used inside @wordpress/scripts:
https://github.com/ampproject/amp-wp/pull/2000/files#diff-11e9f7f953edc64ba14b0cc350ae7b9dR10

which is exactly the same solution as @youknowriad shared in Gutenberg context.

For me the most annoying part is the default entry configuration with src and build. This might work well if you just have a single block in your plugin, but not when it is a bit more complex. Also, as Morten mentioned, adding more modules is often needed. But I think it is fine to just extend the config at this point. It's really straightforward.

As always, we wanted to start with a very limited set of features and see how plugins use it before making further decisions. I want to play a bit more with wp-scripts start/build next week as it might work with the default CLI arguments webpack can process (unless config enforcement makes it to ignore those args).

In the case of Gutenberg, we have a new use case (#14497) where we would need to tweak an entry point, output folder, disable externals and probably handle CSS imports :)

[youknowriad]

In the case of Gutenberg, we have a new use case (#14497) where we would need to tweak an entry point, output folder, disable externals and probably handle CSS imports :)

I don't know yet if we should implement a way to disable the externals, I'm not certain yet that this is something WordPress developpers would need. but yeah a "CSS build command" (to match Gutenberg build tools) would be a good idea.

[mor10]

This looks relevant as an example: https://storybook.js.org/docs/configurations/custom-webpack-config/

[mor10]

To help others who will have the same question I've proposed an update to the documentation complete with a simple code example. See #14590.

[aduth]

Unless I've totally misunderstood our build process, the proposed changes at #15226 pose an interesting related requirement in Gutenberg needing to opt-out of the default Babel processing. The most straight-forward option here is to unset all of the module.rules it inherits. This works partly by virtue of the fact that the Babel loader is the only entry included here. If we were to add more default rules in the future, it might require us to rethink how we'd recommend opt-in/opt-out for specific behaviors.

While simple rules could be done as such:

module: {
	rules: defaultConfig.module.rules.filter( ( rule ) => rule.use !== 'simple-loader' )
},

...the current Babel loader configuration is a good example of a not-so-simple rule, and would be far more convoluted to exclude:

gutenberg/packages/scripts/config/webpack.config.js

Lines 37 to 60 in c8695f7

	{
	test: /\.js$/,
	exclude: /node_modules/,
	use: [
	require.resolve( 'thread-loader' ),
	{
	loader: require.resolve( 'babel-loader' ),
	options: {
	// Babel uses a directory within local node_modules
	// by default. Use the environment variable option
	// to enable more persistent caching.
	cacheDirectory: process.env.BABEL_CACHE_DIRECTORY || true,
	// Provide a fallback configuration if there's not
	// one explicitly available in the project.
	...( ! hasBabelConfig() && {
	babelrc: false,
	configFile: false,
	presets: [ require.resolve( '@wordpress/babel-preset-default' ) ],
	} ),
	},
	},
	],
	},

[shivapoudel]

@aduth How can we extend these options for sass-loader in the extended webpack.config.js config?