[zapt02]

Getting older projects to run was a huge pain for me when I started working with JavaScript, but I have found two easy steps to get around this:

1. Use nvm + an .nvmrc file in your project to pin the major version of Node.js you are using. I recently got a five year old Node 8 project up and running with no issues using this method.

2. Try to avoid packages that has binary dependencies (like node-sass). 99% of binary issues are fixed when using the correct Node version, the only other problem that can occur is if you switch architecture (eg. x86 => ARM).

[TimTheTinker]

We recently solved this problem org-wide with Volta. It allows pinning both the Node and package manager (npm, yarn, etc.) version in each project's package.json file.

Even better, Volta automatically uses whatever node and package manager versions are declared in package.json -- no explicit call required. In other words, `node -v` and `npm -v` always return the version specified in package.json. It's been helpful for working with hundreds of repos and keeping CI and local dev synced on which versions to use automatically.

[doodlesdev]

Why rely on nvm to pin the NodeJS version you are using? That's natively supported as a field in your package.json [0], assumimg you're using npm/yarn/pnpm (you are).

Example:

  {
    "engines": {
      "node": ">=0.10.3 <15"
    }
  }

Also, god forbid you are actually running anything using Node 8 and whatever dependencies you have there, that's a recipe for security disaster.

The truth is that to use the NodeJS ecosystem we must have the discipline to keep projects up-to-date. I personally have a policy to update all my NodeJS projects at least yearly, even if they are abandoned, this includes all dependencies and the NodeJS version. Because I do it often most of the times there are not many problems to keep it working, and consequently updating is fast, but if I leave it for a few years and then come back I'll be in for a (bad) surprise.

[0]: https://docs.npmjs.com/cli/v9/configuring-npm/package-json?v...

[telotortium]

Mostly because you want your project to just work. You've tested your project with a certain version of Node, and you want to ensure that you use the same exact version when you come back to the project in a year and want to perform some minor updates. You can set the node constraint in package.json, but that doesn't install the correct version of Node for you, unlike nvm.

[doodlesdev]

Well that makes sense, as long as the developer running the code has nvm installed. Does nvm-windows read and install the versions in these nvmrc files? If it does your strategy is indeed pretty cool and I might start doing it myself. I wonder if there's any way to force specific versions of NodeJS without relying on nvm or some compatible tool.

edit: someone here in this thread suggested Volta [0] which seems literally like what I was looking for. No need for the nvmrc as it simply follows what's in the engine property of the package.json. Even better is that it's not a weird massive shell script but instead an actual program written in Rust. I'll have to try it out sometime.

[0]: https://volta.sh/

[telotortium]

Wow, Volta does look like exactly what I've been looking for.

[zapt02]

npm can't install the correct version of Node to use automatically, but nvm can using "nvm i"

[nicoburns]

If you use a `.node-version` file it will work with both nodenv and asdf

[eurasiantiger]

nvm is slow when changing directories, fnm is a fast drop-in replacement

[doodlesdev]

How does fnm compare to volta [0] if you don't mind me asking? I see both are written mostly in Rust instead of being bloated shell scripts, although I'm not sure why choose one over the other.

[0]: https://github.com/volta-cli/volta