-
-
Notifications
You must be signed in to change notification settings - Fork 724
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
Webpack, dev. env: Fix configuration export #10631
Webpack, dev. env: Fix configuration export #10631
Conversation
341b3ba
to
456fc3e
Compare
Oh, sorry I missed that. In fact, apparently there is a lot of release notes that I missed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
module.exports = environment.toWebpackConfig() | ||
module.exports = config; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that we were exporting the original config instead of the changed config, so this change makes sense 👍
Actually, this seems not solve the original issue: I can still observe the bug with the configuration.
or in the rails console:
|
I spend a lot of time, trying to solve what's happening here, without any success ; actually I'm even not sure on how to reproduce the issue! I think it's great if we could start working on Rails Assets Management pipeline to remove webpack(er) and having a up-to-date assets management system. Note: from V3 to V4 migrating guide of webpack-dev-server they recommend to use webpack >= 5.
|
Hi @jibees |
Yep, you're right, this does not solve anything. Sorry, that's why this was back to |
456fc3e
to
b9bacba
Compare
with the hash
No files are created with this hash since compilation has not started through webpack.
( My (partial) conclusion is: there seems to have a de-synchronization between |
A hash is usually unique to some input. If you don't change the input then the hash stays the same. So it seems like webpack-dev-server has some changing input which webpack doesn't have. Does it somehow include some already compiled files again? Or is it including a timestamp even though it shouldn't? It could be a bug but these are just theories. I haven't looked into this. Shall we just abandon webpack-dev-server? If we move to another tool, we won't have that feature anyway, right? It just means that Rails has to recompile with webpack on a new request after changing assets and the browser won't reload automatically. |
This causing issue for the docker environment as well. Just noting my observation so far :
If I apply @jibees fix then webpack generate a Edit : I think the following fix is working at least in a docker environment, const environment = require('./environment')
const config = environment.toWebpackConfig();
config.output.filename = "js/[name]-[hash].js";
module.exports = config; |
b9bacba
to
17285a8
Compare
thanks @rioug for spotting that. I was pretty sure that I already removed that test in my commit, but indeed no. I tried with your suggested solution (which I think I already tested): it does not work for me as expected. I always have some |
I played around with this a little bit more with a docker setup. I can see webpack-dev-server recompiling file and updating I realise this is not supper helpful ... |
Same here (not using docker) |
Looks like the issue is coming from the upgrade of |
17285a8
to
6e34f61
Compare
I rebased and removed the minimum version as we are still on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I can see this is now just a one-line config change, which looks good to me.
It looks like it has already been dev tested, but I'll give it another go.
✅ Looks good, I can see public/packs
is created, and local server works. I see a couple of image load errors, but they are active_storage images and probably due to my local data.
✅ Deployed to staging, no console errors.
Ready to merge?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we are trying to fix a workaround which was only introduced by the incompatibility of webpacker versions. We should restore the original file:
process.env.NODE_ENV = process.env.NODE_ENV || 'development'
const environment = require('./environment')
module.exports = environment.toWebpackConfig()
Investigating this I found that we are changing the filename generation to use hash
instead of contenthash
. But contenthash
is recommended and in use by default. I guess that the now reverted version bump changed the naming which brought up this incompatibility. We can now use the default config again.
Sources:
@mkllnk |
We used to override the output filename but this was a misunderstanding of an error (due to webpacke(r) incompatibles versions) https://medium.com/@web_developer/hash-vs-chunkhash-vs-contenthash-e94d38a32208 webpack/webpack.js.org#2096 Context: openfoodfoundation#10631 (review)
What? Why?
Since #10568 we changed a bit the configuration options for webpack in development environement. The PR was incomplete, since it does not export the right value. Change that.
What should we test?
public/packs
folderforeman start
) and check that after requesting a page, folderpublic/packs
is not empty and you don't have any errors in your browser consoleRelease notes
Changelog Category: Technical changes