deps: upgrade npm to 6.1.0

[iarna]

Checklist

• make test-npm passes
• commit message follows commit guidelines

Where this should land

• Node 10
• Node 8

Breaking changes

This is a major release, so it does include breaking changes. They are, however, very minor and important:

• npm update and npm outdated now will not suggest versions greater than the version tagged as latest. This is in alignment with the use of tags for release trains or experimental versions, while not requiring the use of prerelease version numbers.
• npm install will now do its best to avoid versions that are marked as deprecated. That is makes npm deprecate similar to how the gem yank command works in ruby. If you specifically ask for a deprecated version you will still get it.
• npm will now report that it no longer supports node v4 and node v7.

Notable changes

• Flattening npm's dependency tree to take advantage of the MacOS installer rewrite will fixnpm causes the windows installer (.msi) to almost reach MAX_PATH (and using the .zip can easily exceed it) #19449
• npm init now can take an argument and it will run a matching create-… script from the registry. An amalgam of npx and yarn create.
• npm audit provides a vulnerability scanner. The registry side of this will be available soon. Details are discussed in the CHANGELOG
• npm audit fix to help users automatically fix vulnerabilities found with npm audit.
• Webhook management is now included with the cli as the npm hook command. Previously this functionality was found in the module wombat. With webhooks you can request notification whenever a package updates.
• Rewrite binaries less. Previously if we found a CRLF in a binary that had a shebang then we would convert the entire file to unix line endings. With this change we only convert the shebang line itself.
• Eliminate use of new Buffer in npm
• Rewritten and prettier npm view
• npm pack and npm publish previews when running them with --dry-run
• npm ci, new, faster, lock-file only install mode and npm cit to install and test
• Automatic git merge conflict resolution on conflicts in lock-files.
• A slew of bug fixes are stabilizing lock-files when using partial installs (eg, --only=production, --no-optional, etc)

Changelogs

• v5.7.0
• v5.7.1
• v5.8.0
• v6.0.0
• v6.0.1
• v6.1.0

[ChALkeR]

/cc @jasnell

[Trott]

Rubber-stamp LGTM if Ci is green. Probably want to run CITGM too?

[jasnell]

This is likely semver-major.
Without explicit TSC sign off it will not land in 10.0.0.

[Trott]

@nodejs/tsc I'm labeling this tsc-review. Please indicate endorsement or opposition to landing this in 10.0.0 with a 👍 or a 👎 on this comment. Of course, feel free to leave a comment yourself if you want to explain your position or ask a question.

[EDIT: Just to make sure there's no confusion, 👍 means you approve landing this in 10.0.0 and 👎 means you are opposed to it. Heck, let's throw in 😕 for anyone who wants to indicate they have no opinion either way, basically abstaining.]

[ChALkeR]

@Trott it should be noted that this is not 6.0.0 yet — it looks like 6.0.0 hasn't been tagged.
See https://github.com/npm/npm/releases/tag/v6.0.0-next.2

@iarna Is this WiP? What's the ETA for 6.0.0?

[iarna]

@ChALkeR Our plans over the last several months has been to only badge 6.0.0 in conjunction with the Node 10 release, assuming npm6 lands in Node 10. The version badged as 6.0.0 and tagged as latest will otherwise be exactly the same as 6.0.0-next.2. (I have a sneaking suspicion that our plans were not communicated and coordinated where I thought they were, so if this is the first you all are hearing of this, I appologize.)

[MylesBorins]

@iarna what are the semver major changes from 5 -> 6

Is it possible that this could be semver minor? If so we could also backport to 8.x

[iarna]

@MylesBorins I think I answered all these questions in opening:

The major changes are described under "breaking changes" in the summary. They are quite minor but they aren't semver minor. I'm of the opinion that they're valuable enough that we should lobby to include them in Node 8, but YMMV.

And if you look under "where should this land" I said:

Node 8; … If we all end up deciding that's not the way to go, I do have an alternate release line with everything but the breaking changes here that I can PR for it.

There's a 5.10.0 rc currently published, but I'd want to do a 5.11 with the non-breaking things from 6 if it's decided that Node 8 can't take 6.

[mcollina]

Considering the status of things, +1 to fast-track with CI and CITGM ok.

[ChALkeR]

Our plans over the last several months has been to only badge 6.0.0 in conjunction with the Node 10 release, assuming npm6 lands in Node 10. The version badged as 6.0.0 and tagged as latest will otherwise be exactly the same as 6.0.0-next.2.

@iarna Yes, that looks good to me then. Huge +1 to getting npm@6 into 10.0.0.
That said, I did not do a proper review of this PR — don't consider this comment as such.

+1 to fast-track

@mcollina I don't think this could be fast-tracked, could it?

[mcollina]

If we plan to release on Tuesday 24th, there won’t be 72 hours (weekend time) to be able to issue another rc with this in.

If we want to have this in 10.0.0, this should have landed weeks ago. The longer we wait the worse it’ll get.

We need TSC approval anyway.

[addaleax]

As I understand #20121 (comment), we essentially want a @nodejs/tsc vote for this.

I’m okay with landing this in 10.0.0, but yes, it’s way past the deadline and not exactly a trivial change, so I think it would be a good option to include it in the first semver-minor release, given how small the actual breakages here are.

[jasnell]

No, this pr cannot be fast tracked in the normal sense. It's too large, needs more review, and adequate consideration. I'm leaning strongly against rushing it in to 10.0.0 and potentially landing it as a minor in a 10.x minor later.

[cjihrig]

+1 to landing it in a semver minor.

[joyeecheung]

I am leaning towards landing it as semver minor as well

[mcollina]

I’m also +1 to landing as a minor after 10.0.0 is released as well.

[MylesBorins]

+1 for semver minor after the release. Good precident for landing it on 8.x

…

On Sat, Apr 21, 2018, 11:07 AM Matteo Collina ***@***.***> wrote: I’m also +1 to landing as a minor after 10.0.0 is released as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20190 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV832X4VRsisU0l_tAC7vUyZqgPSDks5tq0s5gaJpZM4TeUV9> .

[TimothyGu]

+1 on landing this as semver-minor.

[mhdawson]

+1 on landing this as semver-minor after the release.

[jasnell]

Removing this from the 10.0.0 milestone.

[Trott]

Seems like there's consensus on landing this in 10.x but not 10.0. Removing tsc-review label. Can re-add if there are advocates for landing in 10.0 and not a subsequent 10.x release.