Mangled locale placeholder makes it through to HtmlWebpackPlugin

[madelson]

Bug description

I am trying to use webpack-localize-assets-plugin alongside html-webpack-plugin. My path starts with [locale] but in the compilation process this gets replaced with [locale:b64b2e3f]. Not the end of the world, but makes the work of replacing this with the appropriate locale name in the HTML generation a bit more complex.

It would be great if the original path name could be preserved.

Reproduction steps

Straightforward usage of both plugins (let me know if more is required).

Environment

• webpack-localize-asets-plugin version: 1.2.4
• Webpack version: 5.52.0
• Operating System: Windows 10
• Node version: 14.17.3
• Package manager (npm/yarn/pnpm) and version: npm 7.20.0

[lewismoten]

I'm looking at various ways to integrate localization into my project. I just installed this and I seem to be running into the same problem.

webpack.config.js

const config = {
  output: {
    filename: '[name].[locale].js'
  },
  plugins: [
      new LocalizeAssetsPlugin({ warnOnUnusedString: true, locales }),
      new HtmlWebpackPlugin(),
  ],
}

dist/index.html

<script defer="defer" src="main.%5Blocale%3Ab64b2e3f%5D.js"></script>

Dist files

• 315.en.js
• 315.en.js.map
• index.html
• 315.es.js.map
• 315.es.js
• main.en.js
• main.en.js.LICENSE.txt
• main.es.js
• main.es.js.LICENSE.txt

Environment

• webpack-localize-assets-plugin: 1.4.1
• webpack: 5.64.4
• Operating System: macOS Monterey 12.0.1
• Node version: 17.1.0
• Package manager: npm 8.1.4

Here is the commit where I attempted to set it up lewismoten/schmuck-miser@61314fe

[privatenumber]

Thanks for the reproduction @lewismoten.

What's your expected behavior?

I'm thinking instead of dist/index.html, it should emit dist/index.en.html which loads main.en.js (and so forth for each locale).

I haven't used HtmlWebpackPlugin but happy to review any PR to add support.

[lewismoten]

Sorry about the delay in getting back. As my project is still in the early stages of layout out architecture, I checked out a few other libraries and settled on something that I didn't need a plugin for localization with webpack. You are correct in your assumptions of expected behavior.

[techtruth]

I'm not sure why this broke in the recent version upgrades. I was able to tag [locale] successfully before some version updates to webpack/htmlplugin. I attempted to look inside https://github.com/privatenumber/webpack-localize-assets-plugin/blob/develop/src/multi-locale.ts for the a logical place to get around this, but i dont seem to be able to if all webpack spits out is locale:b64b2e3f with url encoded text.

I expect that if webpack would correctly leave [locale] alone, then this plugin could pick it up and all would be well. Is this a reasonable assumption?

Also, if the tag for locale is fixed to [locale:b64b2e3f], could this plugin register that tag as it does [locale] and it would be a simple string check on this side then. This i expect is less likely... but worth asking.

I will ask on the html webpack plugin issues and see if this can be fixed by allowing locale to pass unmodified, or something.

[techtruth]

I have managed to work around this for now by doing a manual replace on the string "%5Blocale%3Ab64b2e3f%5D" with my desired locale. The documents still build inside the correct folders en/es/ko etc. The old behavior was better I think.

[privatenumber]

If anyone is willing to make a minimal reproduction repository (only webpack config), I'm happy to take a look.

[ShoryuKyzan]

I'm not in the know about how to actually get locale hooked into an app or interacting with html-webpack-plugin, this plugin only seems to generate the bundles. Something must intentionally load them.

I found where that string comes from in this plugin tho:
jantimon/html-webpack-plugin#1753 (comment)

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)}]`;

We hooked HtmlWebpackPlugin.getHooks(compilation).beforeAssetTagGeneration.tapAsync( to search for this string in asset filenames and intentionally load the bundle we want.

Hot module reload also broken:
Something similar is done in multi-locale.js for function calls, a replace with a placeholder at one point then replacing it later with the constant in thisCompilation.
I believe this is breaking Hot module replacement because the updated bundle is emitted before the replacement is made. Perhaps thisCompilation is the wrong hook or something. I'd have to see what hook HMR uses to emit things.

[pros2s]

can you tell me how did you replace theese sybmols %5Blocale%3Ab64b2e3f%5D to correct locale?

[ShoryuKyzan]

A bit of an update
I've tested out the patched version for hot module reloading only.
It doesnt change the placeholder thing.

Working with the author to eventually get this in here. #66

You can install it here:
https://github.com/ShoryuKyzan/webpack-localize-assets-plugin/blob/shoryukyzan/hot-module-reload/README.md