-
Notifications
You must be signed in to change notification settings - Fork 133
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
npm currency on Node v12 #869
Comments
@mcollina Are your Node.js versions off by 2? i.e. delay to v15 vs do it before v14 goes LTS? |
Yes, updating |
FWIW, while I'm sure that 7 will bring along many improvements, I'm hesitant to try to commit to anything for 14 so early before 7 is released. We've had issues with npm major bumps in the past so I'd much prefer taking it slow. |
cc @nodejs/lts @nodejs/releasers
If the change is semver major then it should have to wait until 15.x, unless a case can be made on security grounds. If we deem the change not to be semver major (i.e. minor) then we could land in 14.x any time before it goes into maintenance (i.e. even after it goes LTS). Once in LTS we would typically want such an update to go out in current for 2 weeks (or even longer ("baking-for-lts") if it is deemed risky) before being backported. Do we even have a rough timeframe as to when npm 7 is expected? |
It is likely to be a semver-major change with some default behavior changed. |
If it wasn't major, it'd still be npm 6 :-) |
:-) The only other occassion I can recall where we bumped an npm semver-major in a release line was going from npm 1->2 in Node.js 0.10.x and that was done for security reasons. |
Given that end users can update to 7 on their own I'd lean towards deferring to 15.x in order to not introduce breaking changes. |
In particular, npm 7 will start failing the install if peer deps are invalid, which will likely reveal to a lot of users that their dependency graphs are invalid. I would definitely suggest deferring it to node 15. |
We discussed this during today's Release WG meeting (nodejs/Release#579, https://www.youtube.com/watch?v=yh0_euMCJzw). Consensus there was to wait for the npm 7 beta(s) (expected in summer) and see how it affects the ecosystem before making further decisions. |
The only breaking change that is likely to be unwelcome is the automatic handling of peer dependencies, as @ljharb mentions. Otherwise, I would say that Node 14 should take in npm v7 as soon as it's GA. There are two mitigating factors to the peer deps issue that still make me think it's a good idea, though. A new config option Without The first mitigating factor is that, prior to release, npm v7 will detect unresolvable tree errors, and suggest that the user try again with the I think that's probably enough to make it acceptable to pull into Node 14. If others disagree, we can also ship with a It's somewhat disingenuous to ship npm v6 along with something considered "long term support". npm v6 is already in somewhat of a "minimum necessary maintenance" level of attention and support. There are known bugs and frequently requested features that are just too expensive to address in v6, since they would require the massive refactoring that has already gone into npm v7. I'm biased and optimistic, of course, but once npm v7 is out in the wild, it'll be hard to justify continuing to ship a package manager that is objectively worse. |
@mcollina can this be closed as the we deferred to 15.x? Backporting can be handled as a separate conversation if/when that makes sense. |
Node v14 currently ships with npm v6 as Node v12 does. However they recently announced npm@7 (https://blog.npmjs.org/post/617484925547986944/npm-v7-series-introduction).
This seems like a semver-major change for us, so it's likely better to delay to v15. However there are a lot of good reasons to be updating it before v14 goes LTS.
Wdyt folks?
The text was updated successfully, but these errors were encountered: