Block not working when using cutom webpack

[ivanjeremic]

In the newest version of create/block when I add a custom webpack.config.js with

const defaultConfig = require("@wordpress/scripts/config/webpack.config");

const webpackConfig = {
  ...defaultConfig,
  entry: {
    ...defaultConfig.entry,
    front: "./src/front.js",
  },
};
module.exports = webpackConfig;

the block does not work anymore and only the fron.js is in the build folder no index.js did something change in create/block and we need to do it different now?

[t-hamano]

How about changing it to ...defaultConfig.entry()?
Because the default entry is a function called getWebpackEntryPoints.

[onetrev]

Hey @t-hamano, I've seen this recommended a number of times, including last year by @ryanwelcher in his helpful "Customizing your @wordpress/scripts build process" tutorial video. But oddly I had same problem reported here in that I had to actually use ...defaultConfig.entry() otherwise the bundle files (index.js, index.asset.php, etc) were not created.

Has something changed recently or are some of us doing something wrong? :)

[t-hamano]

I have been testing various versions of the scripts package and have discovered that starting from version 27.0.0, when extending the entry point using getWebpackEntryPoints(), assets are no longer generated correctly. From my understanding, the getWebpackEntryPoints() function is just an internal function, and it seems appropriate to use defaultConfig.entry(). With defaultConfig.entry(), it should work even with scripts versions lower than 27.0.0.

However, there is no clear example of how to extend the entry point, so an extension example using getWebpackEntryPoints() might have been introduced, as seen in this developer blog post. It might be a good idea to add an official code example for extending the entry point to the README of the scripts package.

cc @gziolo

[gziolo]

We only mention extending the existing default webpack config:
https://github.com/WordPress/gutenberg/tree/trunk/packages/scripts#extending-the-webpack-config

It was never mentioned in the documentation that we support low-level functions used by the config. They aren't part of public APIs and it's noted in that section:

Future versions of this package may change what webpack and Babel plugins we bundle, default configs, etc. Should those changes be necessary, they will be registered in the package’s CHANGELOG, so make sure to read it before upgrading.

Another note from the README: https://github.com/WordPress/gutenberg/tree/trunk/packages/scripts#advanced-usage:

In general, this package should be used with the set of recommended config files. While it’s possible to override every single config file provided, if you have to do it, it means that your use case is far more complicated than anticipated. If that happens, it would be better to avoid using the whole abstraction layer and set up your project with full control over tooling used.

[t-hamano]

Thanks for the reply. Is it then better to leave the method for extending entry points undocumented?

[gziolo]

You can remove it from the documentation, but all the online tutorials and code repositories are available, so people will keep trying and reporting back here 🤷🏻

I think we should keep iterating on the default config for the wp-scripts build so people have less reasons to add their custom config. Example issue that would help: #55936 with that. There are more similar issues filed.