build: Upgrade pipelines to Node16 + upgrade nvm recommendation

[andre4i]

Description

Refreshing #13807

Update the recommended versions of Node.js for developers to use, as well as the version used by CI.

This updates from version 14 (which goes out of support on 2023-04-30) to version 16 (which goes out of support on 2023-09-11).

The minimum, as enforced by the root package.json's "engines" block is not updated to 16 yet. This can be done after a migration period.

This has no impact on the produced packages, but will allow (but not yet require) developers working in this repo to upgrade.

Users of nvm can upgrade by running: nvm use && rm -r ./node_modules/ && pnpm i in the root of the repo. Deleating the node_modules directory is needed to trigger reinstalling of nodegit to avoid an "Error: Module did not self-register" when building our codebase.

Some of the packages still use npm (and not pnpm). If working on those packages, you may want to downgrade npm to version 6 after upgrading node so that you avoid converting package-lock files to the new format unexpectedly.

Reviewer Guidance

Feedback on this process, as well as the actual implementations / diff is encouraged.

Questions:

1. Do we want to wait for the rest of the usages of npm to migrate to pnpm? (Perhaps before this, or maybe just before updating the minimum version?)
2. Is there anywhere in our docs that needs updating?

[CraigMacomber]

I think #13807 Has a better description (it explains why you have to remove node_modules, links to nvm docs, notes the relevant date etc.). I recommend including more of the details from it. Also I think you missed a "`" in the last line.

[andre4i]

Hey @tylerbutler

Any ideas why this is failing?

Run JulienKode/pull-request-name-linter-action@8c05fb989d9f15[6](https://github.com/microsoft/FluidFramework/actions/runs/4410527518/jobs/7728089296#step:5:7)ce61e33754f9802c9d3cffa58
Error: Error: subject-empty:subject may not be empty
type-empty:type may not be empty
Error: subject-empty:subject may not be empty
type-empty:type may not be empty

[tylerbutler]

Changes look good. I would like the server folks to take a look too because this change may impact some of their workflows. I suggest posting to the Teams channel and I can mention specific folks if needed.

[CraigMacomber]

Changes look good. I would like the server folks to take a look too because this change may impact some of their workflows. I suggest posting to the Teams channel and I can mention specific folks if needed.

Looks good to me too now, but Tyler's suggestion seems like a good idea before we merge this.

[ChumpChief]

Some of the packages still use npm (and not pnpm). If working on those packages, you may want to downgrade npm to version 6 after upgrading node so that you avoid converting package-lock files to the new format unexpectedly.

It seems like it would make more sense to just upgrade the lockfiles - is there any reason to keep them in old format after this upgrade? I can imagine that pnpm would make this moot but in the meantime seems fine to move forward?

[CraigMacomber]

Some of the packages still use npm (and not pnpm). If working on those packages, you may want to downgrade npm to version 6 after upgrading node so that you avoid converting package-lock files to the new format unexpectedly.

It seems like it would make more sense to just upgrade the lockfiles - is there any reason to keep them in old format after this upgrade? I can imagine that pnpm would make this moot but in the meantime seems fine to move forward?

We are not upgrading the minimum supported version of the tools yet. People modifying dependencies of packages using npm can simply not upgrade node yet or can upgrade then downgrade npm (or can upgrade their package when they modify it). Since using old npm with new node is more supported than using new npm with old node (at least I think this is the case) this seems like a better incremental approach than the other way (update npm first).

Instead of being incremental we could force everyone to upgrade node at the exact same time, and also upgrade npm and the lock file. This seems risky as it would be a large source change (a pain to revert) and likely to break someone (and thus need to be reverted). This seems like a worse option.

Thus I think the approach proposed here is best. I'm biased though as it was my design and I mainly work with pnpm packages and have done this same migration this way before.

[ChumpChief]

Instead of being incremental we could force everyone to upgrade node at the exact same time, and also upgrade npm and the lock file. This seems risky as it would be a large source change (a pain to revert) and likely to break someone (and thus need to be reverted). This seems like a worse option.

I might be missing the risk here - afaik the package-lock format change shouldn't introduce anything beyond changes to the package-lock.json files, and the actual install should remain the same.

Also IMO we should move straight to 18. 16 is already in maintenance and will go out of service in under 6 months (and we'll have to do this again).

[CraigMacomber]

Instead of being incremental we could force everyone to upgrade node at the exact same time, and also upgrade npm and the lock file. This seems risky as it would be a large source change (a pain to revert) and likely to break someone (and thus need to be reverted). This seems like a worse option.

I might be missing the risk here - afaik the package-lock format change shouldn't introduce anything beyond changes to the package-lock.json files, and the actual install should remain the same.

Also IMO we should move straight to 18. 16 is already in maintenance and will go out of service in under 6 months (and we'll have to do this again).

The risk is mainly a risk of having annoying merge conflicts if someone makes a dep change after we forced everyone to update before we realize it broke something and had to downgrade. Not a major risk, but we can avoid it by letting people opt into upgrading and then downgrade themselves if there is an issue instead of having to revert the upgrade.

We should NOT go straight to node 18 until we have a clear story about what our minimum supported Node version for running the server code is and have tests for it. Right now there might be people using the server with node 14 or 16, and we don't have a good way to ensure they are supported other than using the oldest node version we reasonable can. Migrating to 16 is only ok because we don't really need to support any possible users for Node 14 for very long so they probably won't break. Its still a risk, but I think its one we need to take, while I think going to 18 would be premature.

Also I don't want to delay getting off node 14 to try and aim for 18: it might have additional issues. I do hope work on that migration will start as soon as this is done, and that someone is working on node version compat testing.