-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[locale] variable in filenames mangled to [locale:b64b2e3f] when using tag from another plugin #1753
Comments
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
Correct behaviour with
|
Hi, I've looked into this a bit further, and I'm a bit ignorant of how this plugin is meant to be used.
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. As I said before, I don't know the big picture of how to load in the bundles without doing something intentional. |
Somebody can provide reproducible test repo, thank you |
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 🖥
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.
The text was updated successfully, but these errors were encountered: