wp-scripts production builds with name conflicts

[chimok]

Description

I use @wordpress/scripts for my plugin and for the theme and run regularly into trouble my production builds do behave/work very different compared to the non-minified dev build.

Because it generates functions like a() or b() it's possible it conflicts with other minified code. I saw such problems occur in the past and should be fixed: #27985

But I still have it. @gziolo Let me know if you need more information.

Step-by-step reproduction instructions

1. Create a plugin using @wordpress/scripts
2. Create a theme using @wordpress/scripts
3. Add Javascript in both, the theme and plugin
4. Change the package.json so the build task will generate theme and plugin
5. run npm run start - everything should work as expected.
6. Generate a production build with npm run build
7. Now everything "may" work or not because minified function names can conflict.

Screenshots, screen recording, code snippet

No response

Environment info

• Wordpress 6.3.2
• Using DDEV with Bedrock composer setup
• package.json and node_modules in project root shared with custom theme and plugin

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[gziolo]

Can you share more details about your configuration and structure of the project, the errors you see printed? Do you have two package.json files for each parts – the plugin and theme. Do they use unique name fields in package.json?

The issues you referenced was about the lack of support for unique names for variables generated by webpack. The way it works with webpack 5 is through output.uniqueName:

A unique name of the webpack build to avoid multiple webpack runtimes to conflict when using globals. It defaults to output.library name or the package name from package.json in the context, if both aren't found, it is set to an ''.

[chimok]

I have only one package.json and node_modules and run wp-scripts twice, for generate a build folder inside the plugin and theme.

So you think that is the reason why conflicts can happen? Because name field in package.json is same?

[gziolo]

@chimok, have you tried using two entry points with a single wp-scripts command as an alternative:

{
    "scripts": {
        "build": "wp-scripts build entry-one.js entry-two.js"
    }
}

It's also possible to create a custom webpack config like as covered in https://github.com/WordPress/gutenberg/tree/trunk/packages/scripts#extending-the-webpack-config. In this case, maybe it even makes sense to export two configurations from a single file: https://webpack.js.org/configuration/configuration-types/#exporting-multiple-configurations.

[chimok]

@gziolo If I take your suggestion, how can I configure the destination of my build folder? Update: I saw now the second link in your answer and it answers the question. I will try it and report back.

The plugin build folder (web/app/mu-plugins/vdplug/src/entry-one.js) have to be:
web/app/mu-plugins/vdplug/build

The theme (web/app/themes/vdclassic/src/entry-two.js):
web/app/themes/vdclassic/build

Of course I could move everything from the plugin into my theme or setup a independent build for theme and plugin (the later is the common choice). If you believe that will certainly fix the issue I'll try it. I use the plugin mostly for real backend stuff and theme independent code. Have only one package.json / node_modules is faster and less work for my git pipeline, that's why I choose this setup.

[gziolo]

Have only one package.json / node_modules is faster and less work for my git pipeline, that's why I choose this setup.

I hear you and can only say that both Gutenberg and WordPress core took the same approach to orchestrating everything from one place:

https://github.com/WordPress/gutenberg/blob/ea2230d38c5ce4a3b73f7030e94abdfdbbac3f5d/webpack.config.js#L9L14

There is single config file for webpack with multiple different configurations 😀

[chimok]

Everything worked well. However, it was a lot work because I want the auto. block.json parsing and this part wasn't easy to reuse because it requires to set WP_ENTRY environment. I don't know to to set this for each entry? So I create my custom version of getWebpackEntryPoints basted on the code here:

gutenberg/packages/scripts/utils/config.js

Line 191 in ea2230d

function getWebpackEntryPoints() {

I close the ticket since it's possible with the custom webpack.config.js