Update dependencies #45
Comments
|
Woah, good research. I agree with your changing to the caret operator. So the conclusion is that we can upgrade node-libs-browser for webpack v1, or what is the next step? |
|
Yes, webpack v1 should use the latest node-libs-browser module. The risk of an actual breaking change is very low. |
jhnns
added a commit
that referenced
this issue
Nov 22, 2016
|
These versions shipped with |
jhnns
added a commit
to webpack/webpack
that referenced
this issue
Nov 23, 2016
According to webpack/node-libs-browser#45, the risk of introducing a breaking change with this update is very low.
jhnns
added a commit
that referenced
this issue
Nov 24, 2016
Based on #45, we update the dependencies to the most recent version. Some modules, however, can not be updated to the most recent version because there was a breaking change: ## `buffer` The current `buffer` implementation uses feross/buffer@4.x because feross/buffer@5.x relies on [typed arrays](feross/buffer@5daca86#commitcomment-19698936). This will be dropped as soon as IE9 is not a typical browser target anymore. ## `punycode` The current `punycode` implementation uses bestiejs/punycode.js@1.x because bestiejs/punycode.js@2.x requires modern JS engines that understand `const` and `let`. It will be removed someday since it has already been [deprecated from the node API](https://nodejs.org/api/punycode.html). ## `crypto` We locked `crypto-browserify` at `3.3.0` because `3.4.x` introduced a breaking change by requiring JSON files. We will not upgrade this module for webpack 1 anymore since it will introduce a breaking change for all users that don't have the [json-loader](https://github.com/webpack/json-loader) configured. You can, however, use a newer crypto-browserify version by configuring a [`resolve.alias`](http://webpack.github.io/docs/configuration.html#resolve-alias) and using the json-loader.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I did a quick research for breaking changes of outdated modules. This was necessary because it was unclear why @sokra chose to update to 1.0.0 for webpack 2 but not for webpack 1. This is the result:
Major version bumps (including
0.xchanges)buffer
Breaking change was feross/buffer@5daca86
@fanatid wrote:
Since we should still support IE9 and IE10 out-of-the-box, we should stick to v4 for now.
constants-browserify
The update should be no problem. Some constants have been changed but the usage is very unlikely.
https-browserify
No breaking change
os-browserify
No breaking change
readable-stream
Breaking change was nodejs/readable-stream@53ff397
Doesn't seem to be really breaking? readable-stream was not using semver prior v2.
stream-browserify
The funny thing is: stream-browserify is also using readable-stream for quite some time. We should just use readable-stream.
url
Possible breaking change in defunctzombie/node-url@e5b6f59
However, since this commit brings the url module in parity with node 0.12, it is very unlikely that there is currently frontend code out there which relies on such an old implementation of the url module. It is more likely that we actually fix code because developers assume a more recent implementation of the url module.
We should also switch all dependencies to the caret operator
^to exclude breaking changes from0.xmodules.@sokra @TheLarkInn @bebraw @SpaceK33z
The text was updated successfully, but these errors were encountered: