Add fixed version of the nodejs

[my8bit]

Once I checked out the repository to explore, I found out that extensions/vscode is throwing an error that was caused by the old version of the Node.js that I'm using.

Here is the part of the stack

> [email protected] package
> node scripts/package.js

/home/my8bit/github/continue/extensions/vscode/scripts/package.js:16
  if (error) throw error;
             ^

Error: Command failed: vsce package --out ./build patch --yarn
warning ../../../../package.json: No license field
warning [email protected]: The engine "vscode" appears to be invalid.
error [email protected]: The engine "node" is incompatible with this module. Expected version ">=20.11.0". Got "18.15.0"
error Commands cannot run with an incompatible environment.
 ERROR  yarn failed with exit code 1

    at ChildProcess.exithandler (node:child_process:419:12)
    at ChildProcess.emit (node:events:513:28)
    at maybeClose (node:internal/child_process:1091:16)
    at ChildProcess._handle.onexit (node:internal/child_process:302:5) {
  code: 1,
  killed: false,
  signal: null,
  cmd: 'vsce package --out ./build patch --yarn'
}

Node.js v18.15.0
FAIL: 1

I belive that this might be a good time to include it to prevent the new comments from dealing with this potential issue over and over again and make the explicit version of the Node.js specified.

So I decided to add the .nvmrc file for those who use the NVM manager and specify the version in the packages.json file. I created a draft though because I want to get your opinion about the change if you find it useful to apply.

Also, I discovered some things that I do not fully understand but I'd like to ask them in Discord first.

[my8bit]

and btw @sestinj thanks for building such a great tool

[my8bit]

There is an https://docs.npmjs.com/cli/v10/using-npm/config#engine-strict strict option that will refuse to install dependencies for the older version of the Node.js. We can add that as well to make it more strict even.

[sestinj]

@my8bit Thanks for doing this, I think it's a great addition. Out of extreme caution I think it would be best to remove engines -> node from the package.json at the root of extensions/vscode, reason being that they don't make it clear in their documentation whether this is used to determine whether an extension is incompatible. It would be unfortunate if this caused anyone on older node versions to be unable to download the extension.

And with strict mode, I'd say if an npm i succeeds now with strict mode, no changes necessary, then this can only help

Otherwise I think this looks ready to merge

[my8bit]

@my8bit Thanks for doing this, I think it's a great addition. Out of extreme caution I think it would be best to remove engines -> node from the package.json at the root of extensions/vscode, reason being that they don't make it clear in their documentation whether this is used to determine whether an extension is incompatible. It would be unfortunate if this caused anyone on older node versions to be unable to download the extension.

And with strict mode, I'd say if an npm i succeeds now with strict mode, no changes necessary, then this can only help

Otherwise I think this looks ready to merge

This is a very good point about the version compatibility with VSCode itself. I researched it here a bit and here is what I discovered:

• The VSCode itself is using the >=18.15.x and <19 and 18.17.1 from the main branch to be more specific source: docs, .nvmrc
• My Windows version of the VSCode is using the 18.15.0. You can check your from VSCode itself by opening Help -> About
• At the same time correct code contains the GitHub Actions that use the Node.js version v19.0.0. Theoretically, in setup without change from this, MR allows bundling the version of the extension that uses the incompatible syntax from Node.js v19.0.0 that will not work in the VSCode, that uses v18.15.0. In this case, the code will pass locally and will pass the CI job. Moreover, v19 is not officially supported by VSCode as stated in the docs above. Therefore I configured the pipeline files to use the Node.js version from the .nvmrc from the repo.
• When I started to dive into the issue from the description I realized that it's most probably the local inconsistency but that I do have. I checked the clean installation with v18.15.0 and it worked well for me.

IMHO the safest option is to stick to v18.15.0 (or v18.17.1 or broad version in range >=18.15.x and <19) in .nvmrc and have a centralized and explicit version of the Node.js used across the project locally and on CI.

P.S. I found the issues with ./install-dependencies.sh as well, which I'm going to address in another PR.

[sestinj]

Went ahead and merged with 19.0.0 in .nvmrc just to keep it the same as before (don't want to change too much at once). If 18.... still makes more sense soon can make the change quite easily