Background

• In order to reduce maintenance burden, it's prudent to closely track the upstream vscode project to the extent possible; in this case, the upstream behavior is ambiguous
• We previously pinned Node.js to the major version that we support (14.x) which matches the version that VSCode requires
  • This prevents installation using yarn global add if the running version of Node is newer than the version we are using (this was reported as Installing on Termux failed due to Node version #4225
  • The subsequent fix was to relax the version requirement in fix(package.json): update node version requirements to >=14 #4230, such that either version 14 or any subsequent version, including major versions, can be used
  • We always test with the latest patch release of the 14.x series, and we do not test on other versions which match the wider constraint (currently 15.x and 16.x)
  • This means that we made an implicit assumption that Node.js would maintain backward compatibility indefinitely, or over a large enough window (several years/releases) that the constraint was unnecessary
• Node.js has a deprecation policy and some symbols are periodically renamed or removed, which is a breaking change
• The upstream vscode project does not specify a engines constraint or provide an installation method using npm or yarn
  • However, the developer guide indicates that Node.js 14 is required, and the package.json specifies a dependency on @types/node version 14
• According to @code-asher, there have historically been instances where we supported Node.js 10, and due to breaking changes in the runtime, code-server was not installable on Node.js 12 - thus, breaking changes do seem to happen from time to time
• This decision only affects users that build from source (by installing via yarn install or building code-server manually), since binary builds always include a version of Node.js 14, similar to the vscode upstream packages, which bundle a version of Node.js along with Electron

Current behavior

• We allow installation from source with Node.js version 14, 15, or 16
• We run all of our build and test infrastructure on version 14
• Things seem to work with Node.js 16, but we have not tested and are not sure whether that is a reasonable expectation in general, since it relies on the Node.js maintainers avoiding breaking changes even across multiple major releases

Desired behavior

This is what I hope to determine by starting this discussion. The outcome of this could be:

1. Status quo: we accept the risk that things may break at any point in the future, and allow installation on Node.js version >= 14

   This means that we will continue to allow users to install on Node.js 16 with no guarantee that it will continue to operate correctly and no notice in case it fails, aside from issues.

2. Pin to major version: we revert the change in fix(package.json): update node version requirements to >=14 #4230 and require a matching major version (14.x series only).

   Users with a different Node.js version will no longer be able to install from source, but will instead need to install using the install.sh script or binary builds. This also means that users will be running the same version of Node.js that we test with.

3. Add test infrastructure: we expand our test configuration so that we have coverage for newer versions, so that we have additional confidence that code-server runs on 15.x and 16.x

cc @jsjoeio @vapurrmaid @TeffenEllis @code-asher