Update to npm 8, pin in package.json via volta and corepack

[jakebailey]

Fixes #49726

But, I'm a bit apprehensive about this just because we have to make sure people have upgraded versions of things.

• Volta users will be just fine.
• corepack users, maybe not? Corepack enable does not symlink to npm.js nodejs/corepack#138
  • It works, but you have to run corepack enable npm.
• nvm for *NIX, should be okay Support for Corepack nvm-sh/nvm#2803
• nvm for Windows, should be okay. Corepack is skipped with Node 16.9.0. Unable to access it. coreybutler/nvm-windows#660
• fnm users, maybe not? Better Corepack support Schniz/fnm#566
  • I've had success with corepack under fnm with the same corepack enable npm.
• n should work too.

We'd be better if people just used newer versions of node (16+ ship with npm 8), however, I know many people stick with Node 14 as that's the last version with frame restarting for debugging, and that's why our volta config says what it does.

I have a TODO for the workflow, but I need to wait a few days to be able to see if the command it runs actually changes anything. Otherwise, it's not the right way to update the lockfile. Honestly, it's probably better to just have it delete the lockfile and recreate it from scratch. It's run nightly, so I do not expect conflicts given the frequency of the fixups.

[jakebailey]

There doesn't seem to be a way to emulate npm 6's odd side-effect behavior to use for updating dependencies automatically. IMO that's good (I hate side effects), but for our action we need something, so I've done what I normally do for "update everything" scripts and just have it remove the lockfile. This should be okay because it runs every day.

The only remaining thing to do here is likely to add some sort of documentation that suggests using volta or running corepack enable npm (which should work without any extra installing thanks to corepack's inclusion in current Node 14/16 versions). I also will try and add engines that specify the npm version to. Can't use engines, as that is for consumers of the TS package (e.g. to say "we need at least npm vX for our package to install).

[jakebailey]

I'm thinking we don't really have to provide any guidance here; I think if people push bad lockfiles to their branches we'll notice and can advise then.

[jakebailey]

I have absolutely no idea who's the best to review this.

[DanielRosenwasser]

Definitely the best endorsement I could ever receive.

[andrewbranch]

My preferred method of review for this kind of thing is to merge it and see if it causes problems. Seems like you’ve done your research and will recognize if there's some reason we need to roll back.

[jakebailey]

Thanks for the approval.

Do we want to wait for this until after we cut 4.8, or is this low risk enough that it's not going to matter?

[andrewbranch]

I don’t think this has any impact on release considerations.