Repository navigation
npm currency on Node v12 #869
Description
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?
Activity
addaleax commentedon May 20, 2020
@mcollina Are your Node.js versions off by 2? i.e. delay to v15 vs do it before v14 goes LTS?
mcollina commentedon May 20, 2020
Yes, updating
jasnell commentedon May 20, 2020
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.
richardlau commentedon May 20, 2020
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?
mcollina commentedon May 20, 2020
It is likely to be a semver-major change with some default behavior changed.
ljharb commentedon May 20, 2020
If it wasn't major, it'd still be npm 6 :-)
richardlau commentedon May 20, 2020
:-)
For some historical context:
The bump from npm 5->6 was deemed semver-minor for Node.js (nodejs/node#20190) and happened during the lifetimes of Node.js 10 and 8. It does sound like npm 6->7 will be a bigger jump.
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.
mhdawson commentedon May 21, 2020
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.
ljharb commentedon May 21, 2020
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.
richardlau commentedon May 21, 2020
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.
isaacs commentedon May 21, 2020
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
--legacy-peerdepshas been added, which will tell npm v7 to completely ignore peer dependencies, just like npm v6 does. (This config will not be respected innpm ls, so that users can still get alerted about invalid install trees.)Without
--legacy-peerdepsenabled, the install will fail, but not in any kind of catastrophic way, as it will fail during the ideal tree building phase, before anything is written to disk.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
--legacy-peerdepsflag. (We may decide to warn and re-attempt the resolution with this option enabled in these cases, but that strikes me as somewhat over an overstep, since the failure actually is a useful indicator of something the user needs to do.)I think that's probably enough to make it acceptable to pull into Node 14. If others disagree, we can also ship with a
npmrcbuilt-in config file settinglegacy-peerdeps = trueby default. This isn't my preferred approach because it means that the npm bundled along with Node.js will be subtly different from the npm that a user would get by installing it directly. But if there's a huge negative reaction to the peer dep conflict detection, it is a tool in our kit.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.
mhdawson commentedon Nov 23, 2020
@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.