[locale] variable in filenames mangled to [locale:b64b2e3f] when using tag from another plugin

[techtruth]

Current behaviour 💣

When using https://github.com/privatenumber/webpack-localize-assets-plugin it is recommended to insert [locale] inside filenames so that when building multiple locale files, it can be exchanged for the correct value (en, ko, es, en-US, and all those).

Recently after a version update to the latest, [locale] no longer gets left alone for the plugin to pick it up. Instead it outputs [locale:b64b2e3f] in its place, which then throws off the plugin that is expecting it.

It is possible that i misunderstand what the b64b2e3f signifies, and maybe it is predictable in a way that can differentiate en/ko/es and so on.

It is also possible that this isn't a behavior change in the html webpack plugin, but i am getting the asset list from the .beforeAssetTagGeneration.tapAsync tap, and the files are already replaced with locale:b64b2e3f and url encoded, where as before they were set to the proper locale string.

Expected behaviour ☀️

I would expect that html webpack plugin would not alter the [locale] tag.

Reproduction Example 👾

const config = {
output: {
filename: '[name].[locale].js'
},
plugins: [
new LocalizeAssetsPlugin({ locales }), //Plugin that needs locales unmodified
new HtmlWebpackPlugin(), //Our favourite html plugin
],
}

Environment 🖥

Node.js v16.15.0
linux 5.10.0-14-amd64
npm 8.5.5

Its also worth mentioning that this issue has been posted on the plugins issues as well, but it does seem that the issue is lower than the locale plugin can go. privatenumber/webpack-localize-assets-plugin#17

Thanks for reading.

[jfernandezr]

I can confirm the behavior.

The [locale:b64b2e3f] tag is set by webpack-localize-assets-plugin, and webpack is correctly renaming that tag to the proper locale when outputing the JS entry file. So, webpack knows the asset final path.

Using html-webpack-plugin, it does not translate the the [locale:b64b2e3f] tag to point to the localized asset path in the generated HTML or it's not using the final path that webpack uses. The bug is not happening when using html-webpack-plugin version 4.5.2 though.

Bug reproduced with

• webpack 5.74.0
• webpack-localize-assets-plugin 1.5.2
• html-webpack-plugin 5.5.0

Correct behaviour with

• webpack 5.74.0
• webpack-localize-assets-plugin 1.5.2
• html-webpack-plugin 4.5.2

[ShoryuKyzan]

Hi, I've looked into this a bit further, and I'm a bit ignorant of how this plugin is meant to be used.
It appears that the above filename thats emitted is a pre-replacement version of the asset. Its deleted later and replaced with the localized versions.
In localize assets plugin, that string comes from:

multi-locale.js

 - for filenames, this is replaced with the real thing in compilation.hooks.processAssets.tapPromise({
(i might have the wrong hook listed up there)
exports.fileNameTemplatePlaceholder = `[locale:${(0, sha256_1.sha256)('locale-placeholder').slice(0, 8)}]`;

Theres something similar for the localize function name replacement. Its replaced later at thisCompliation hook.

Yeah so, I'm not as familiar with html webpack plugin at all, but from the looks of this whole thing and the documentation of localize assets plugin that there's no mechanism provided to actually load the localized bundle, just to generate it. So you must tell the app to load it somehow.
We had to force a certain locale bundles to load in this hook:
HtmlWebpackPlugin.getHooks(compilation).beforeAssetTagGeneration.tapAsync(

As I said before, I don't know the big picture of how to load in the bundles without doing something intentional.
But this is where that stuff comes from.

[alexander-akait]

Somebody can provide reproducible test repo, thank you