-
Notifications
You must be signed in to change notification settings - Fork 44
Stable hashes #60
Comments
I have the same issue. Added for (const m of chunk.modulesIterable) {
if (typeof m.source === "function") {
console.log(m.resource, m.hash);
console.log(m._source._value.length < 1000 ? m._source._value : '---');
hash.update(m.hash);
}
} Got:
First generated module in the chunk contains absolute paths and brokes contenthash. But both input and optput |
I've been reading docs today and checked the code of this loader and the open issues and it all finally seems to make sense (to some extent at least; see #56; although in my case the paths should not change between the builds, so I'm not sure if this is exactly same as my issue). https://webpack.js.org/contribute/writing-a-loader/
https://github.com/webpack-contrib/script-loader/blob/master/index.js#L13-L15 In this loader, |
Ah well. There's been a PR to fix this for 2 years but not merged, and the loader is no longer supported: |
I'm using script-loader to inject some Foundation JS on our bundles and noticed that if I change the path where the repository is, the
contenthash
changes, this completely broke our deployment pipeline as the assets are generated more than once for different distribution places and the hashes ended up being different.Try it yourselves at https://github.com/gforcada/webpack-stable-hashes
The solution I found myself is move the import to the JS file rather than at the webpack configuration like this:
app.js
require('foundation-sites/path/to/file.js');
webpack.js
Might be something worth mentioning on the README? 🤔
Our webpack configuration is quite complex and it took me a complete morning to pin it down to this specific lines (we have several lines like
'!!script-loader!foundation-sites/dist/plugins/foundation.core.js',
on our webpack configuration).The text was updated successfully, but these errors were encountered: