-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
chore(deps-dev): bump webpack from 4.44.1 to 5.70.0 #11584
Conversation
Honestly, I'm not sure it's worth our time to worry about upgrading Webpack currently. I'd like to upgrade in the future, but, like you said, there's some tradeoffs we need to consider to use Webpack 5. Is there any benefit to us upgrading? |
The main benefit I am doing this for is using the latest features whenever we need to and making version upgrades cheaper once webpack v6 is released for example. The other tradeoff is the I also took a look at the v4.x bundle size vs v5.x bundle size. I was wrong when I said:
It did show the warning on v4.x, and v5.x's bundle is 40 KBs smaller (922 KBs vs 962 KBs). I now think this should be good to go. What do you think? |
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'll merge this into 6.3 just so we err on the side of caution.
Happy to help 👍 |
This PR upgrades webpack from v4.44.1 to v5.70.0.
The affecting breaking change is that, in webpack v4, Webpack used to polyfill node dependencies automatically which had performance drawbacks, in v5 webpack changed this to have people opt-in the dependencies they need for their applications.
Which means we need to install the following 3 dependencies:
My concern is regarding
assert
, it has a conflicting name with node's nativeassert
, which means that we might get a slightly different behavior from node's assert.Not sure if having
assert
as a dev dependency will mean that in production apps using mongoose will use the nativeassert
or the browserify one, but even if production apps will use the nativeassert
, another concern would be that we will have different behavior in the development process and CI will happily pass and we'd know about potential issues too late.So it seems like our options are as follows:
node:
protocol.I'm leaning towards creating an alias to assert and calling it assert-browserify, and only use it for webpack.
What do you think?
Also, after upgrading Webpack started show warnings it didn't previously show regarding bundle size, any idea how we can decrease the bundle size?