deps: upgrade npm to 3.6.0

[iarna]

This is the big one! After this I anticipate getting back into a weekly cadence of upstreaming things to Node.js.

Contains the changes in these releases:

• https://github.com/npm/npm/releases/tag/v3.4.0
• https://github.com/npm/npm/releases/tag/v3.4.1
• https://github.com/npm/npm/releases/tag/v3.5.0
• https://github.com/npm/npm/releases/tag/v3.5.1
• https://github.com/npm/npm/releases/tag/v3.5.2
• https://github.com/npm/npm/releases/tag/v3.5.3
• https://github.com/npm/npm/releases/tag/v3.5.4
• https://github.com/npm/npm/releases/tag/v3.6.0

Notable inclusions are:

• The clarified split between Terms of Service and the CLI's own license (see the discussion in https://github.com/npm/npm/releases/tag/v3.5.1 and Potential Licensing issues with npm #3959 for more context).
• Several important changes to how edge cases involving bundleDependencies are handled.
• Tests don't implode when running under a node prerelease.
• You also only get one warning now about using a prerelease version rather than dozens and dozens from failed engine checks.
• A handful of minor new user affordances in 3.6.0– in particular npm outdated reports linked modules & npm version can now take from-git as an argument.

r: @Fishrock123
r: @jasnell
r: @mikeal

[MylesBorins]

CI: https://ci.nodejs.org/job/node-test-pull-request/1435/
citgm: https://ci.nodejs.org/job/thealphanerd-smoker/52/

[iarna]

Ah I may have stepped on some of your CI– I just repushed with PR-URL in the commit messages.

[zkat]

info note: Most of the licensing stuff covered here was done in LTS with #4110 and #4872 -- these should be the same changes. :)

[MylesBorins]

Doesn't look like it got in the way of the CI job. restarted citgm.

I'm also running make test-npm locally. First run through had two failures, but I think they were related to my settings for progress bar. I've removed that line from my .npmrc and am running again. I'll edit this comment with the results when it is done

[Fishrock123]

@iarna I'm getting what appears to be a new failure:

test/tap/progress-config.js ........................... 4/5 default not ok should be enabled +++ found --- wanted -true +false compare: === at: line: 34 column: 7 file: test/tap/progress-config.js type: EventEmitter source: | t.is(log.progressEnabled, true, 'should be enabled') stack: | EventEmitter.<anonymous> (test/tap/progress-config.js:34:7) 

[MylesBorins]

@Fishrock123 that's the same failure I was getting. Do you have your progress config set off globally atm?

[MylesBorins]

After removing my global setting for progress everything passes as expected

[Fishrock123]

Yeah my progress is disabled. I don't really think it should be picking it up globally though?

[iarna]

I'll make a note to make that test agnostic to your configuration.

[Fishrock123]

@iarna I'm not really sure how npm tests work, my assumption is that it would be ideal to run them as isolated as possible, but perhaps that's not true?

[iarna]

@Fishrock123 The tests broadly assume that you haven't fiddled with the defaults to various config values, which is not fantastic, but is fine for CI (and for the rest of us it's easy to tweak our configs while testing). When we see things where behavior is gonna be substantially different than expect if you change your config we've been trying to explicitly set the config that the test is testing, but it's been an as-we-go thing, not comprehensive.

[zkat]

LGTM here. I assume we'll catch that particular config thing next time around.

[jasnell]

LGTM as well. Incremental steps :)
On Jan 29, 2016 3:20 PM, "Kat Marchán" [email protected] wrote:

LGTM from me. I assume we'll catch that particular config thing next time
around.

—
Reply to this email directly or view it on GitHub
#4958 (comment).

[Fishrock123]

Thanks, landed in d5d301f...18c12bb!

@iarna Just a nit, I had to change the license commit message, it was a bit over 50 chars. :)

[iarna]

@Fishrock123 Ah! I'll watch for that in future