Sometimes you're limited in production by whatever version the OS supports. In the case of Debian installing nodejs doesn't necessarily land you the latest and greatest. The same happens with Python as well. I wish they had a good way to abstract this in Debian and I'm surprised Ubuntu hasn't fully resolved it, I mean Ubuntu does have Snap but I can't trust Snaps fully if the language vendors aren't backing the only available Snaps. But to account for systems where the only version of Node or Python, or whatever is a specific version, you need systems like this.

Why don't you just install the official 'deb' package with the version of your choice?

https://github.com/nodesource/distributions/blob/master/READ...

You can absolutely install the newest version of Python and Node on Debian. It is a little harder than just an `apt-get install`, but very possible.

Of course you can install it. In many environments it's not considered maintainable to deviate from the distro provided and supported version. Especially when you have support contracts from your OS vendor.

If devs want something different from the distro provided libs we typically ask that they use containers or otherwise vendor them.

Ideally we would like our software to depend on the system for the bare minimum and security critical libs like OpenSSL so that Ops is free to switch out the underlying platform with minimal friction.

I have a development server that has some projects mainly written by someone else and one of them specify an old version of nodejs as dependency which breaks by using latest LTS (and I'm too lazy to figure out how to make someone else's code to work on latest LTS) but I don't want to turn nodejs for the entire server to an old LTS.

When I write lambda code for my job, our code currently only supports the node 6 for it's runtime (our system automatically deploys it). I use nvm to help test my code all the time while still having the ability to switch to a more current node for other projects

Are you running your projects directly on your machine? Your’re not using a VM or containers? Don’t you have the “but it works on my machine” problem?

We only run it for quick tests. This is custom code that our main application uses for custom logic that is different for each customer. We can't build it into the main product because not everyone wants/needs it. We always test on the lambdas directly, but we just dev on our machine as that's sometimes quicker.

We never had that issue with node

Here's a couple of use cases:

You maintain a library and you support more than just the latest version of Node. You switch to test compatibility.

You work on a project with a team. Some members of the team work on other projects with other versions of Node. They need to be able to switch.

It's nice to have this when you need to debug issues which only occur on certain versions. A good example would be the recent change of the c++ addon api, which caused my code to crash on some installations while it worked fine on others.

For us, it's about developing on the same node version used in production. That's necessary if you're not deploying to a containerized environment or you're using something completely out of your control like AWS Lambda.

the main reason i use nvm is because its the only way i can use npm i -g.....

You dont need to nvm to do that. You just need to set an alternate "global" path inside your home-directory, instead of one in /usr/lib/node which requires root.

https://stackoverflow.com/questions/14742553/how-to-set-cust...