[v14.x] deps: upgrade npm to 6.14.11

[darcyclarke]

6.14.11 (2021-01-07)

DEPENDENCIES

• 19108ca5b [email protected]
• 7a0574074 [email protected] - devDep

DOCUMENTATION

• 1d235b230 #1881 docs: update link to CLI issues

TESTING

• c0f8ce8fe #1751 add s390x, ppc64 and ppc64el in supported cpu list

@MylesBorins brought it to my attention that #36838 was/is missing the package version bump; I've walked back through our process & queued this net-new PR up - pretty much confirming that there must have been human error during a rebase at some point (apologies on my part there).

Poking @ruyadorno speifically to double/triple check this.

[ruyadorno]

LGTM 👍

[ruyadorno]

Thanks @darcyclarke for taking the time to send a fix 😄 cc @nodejs/releasers

@richardlau I know you just recently cut v10.23.2 that included these changes, from what I see here in this PR it just fixes properly bumping the version number in deps/npm/package.json and updating the deps/npm/CHANGELOG.md file so I'm not really sure if it's worth touching v10 again, let me know what you think 😊

Heads up @BethGriggs I think you want to include this in #37074

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/35789/

[richardlau]

@ruyadorno I had a quick discussion with @BethGriggs last night about Node.js 10.23.2 and both of us were leaning towards cutting a 10.23.3 as it’s otherwise confusing if the included npm is not accurately reporting its version.

As an aside, this PR should probably be targeting the staging branch, which would probably result in fewer changed files if done right now but for v14.x-staging it would probably make more sense to drop (i.e. rebase out) the previous npm 6.14.11 commit first.

[darcyclarke]

Looks like this needs to be rebased against the staging branch. Can update here in a minute*

[MylesBorins]

@BethGriggs @richardlau I've retargeted this against v14.x-staging and it looks like it probably needs to be rebuilt as there is a conflict. It would appear with a quick scan that the update that landed actually only bumped to 6.14.10, so what is shipping in 10.x is in fact accurate, it was the commit that was labelled wrong.

As such I think we need to reland 6.14.11 on both 14 + 12 + 10 (and cut another 10.x). Personally I think it might be simpler to just land the update commit here and then backport to 12 + 10 rather than rebasing out the erroneous commit.. will make backporting simpler. But cool with whatever makes the most sense to folks

[richardlau]

@MylesBorins #36571 updated to npm 6.14.10 and went out in the January security releases.

[BethGriggs]

It would appear with a quick scan that the update that landed actually only bumped to 6.14.10, so what is shipping in 10.x is in fact accurate, it was the commit that was labelled wrong.

I think cc6b695 is the commit that went out in v10.x (cherry-picked from #36838), and that appears to have the content of https://github.com/npm/cli/commits/v6.14.11 (for example, the ini update). My understanding is that we've shipped the npm 6.14.11 content labeled as npm 6.14.10.

I'm leaning towards rebasing out the commit from v14.x-staging, and then just landing an updated PR.

[richardlau]

I think cc6b695 is the commit that went out in v10.x (cherry-picked from #36838),

Correct, #36838 (comment).

[BethGriggs]

I've rebased the commit out of v14.x-staging - should this PR be reopened?

[BethGriggs]

ping @nodejs/npm, was this PR intentionally closed? I'm holding off on v14.15.5 so we can get it in

[ruyadorno]

@BethGriggs I'll follow up and will let you know, thanks!

[ruyadorno]

@BethGriggs here's the follow up: #37173