Skip to content
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

Closed
mcollina opened this issue May 20, 2020 · 12 comments
Closed

npm currency on Node v12 #869

mcollina opened this issue May 20, 2020 · 12 comments

Comments

@mcollina
Copy link
Member

mcollina commented May 20, 2020

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?

@addaleax
Copy link
Member

@mcollina Are your Node.js versions off by 2? i.e. delay to v15 vs do it before v14 goes LTS?

@mcollina
Copy link
Member Author

Yes, updating

@jasnell
Copy link
Member

jasnell commented 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
Copy link
Member

cc @nodejs/lts @nodejs/releasers

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.

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
Copy link
Member Author

It is likely to be a semver-major change with some default behavior changed.

@ljharb
Copy link
Member

ljharb commented May 20, 2020

If it wasn't major, it'd still be npm 6 :-)

@richardlau
Copy link
Member

:-)
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
Copy link
Member

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
Copy link
Member

ljharb commented 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
Copy link
Member

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
Copy link

isaacs commented 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-peerdeps has been added, which will tell npm v7 to completely ignore peer dependencies, just like npm v6 does. (This config will not be respected in npm ls, so that users can still get alerted about invalid install trees.)

Without --legacy-peerdeps enabled, 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-peerdeps flag. (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 npmrc built-in config file setting legacy-peerdeps = true by 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
Copy link
Member

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants