node --update

[flakey5]

What is the problem this feature will solve?

Node doesn't have a built in updater. This makes it a bit bothersome to users when they would like to update as they need to go out of their way to do something that could be a lot easier. Third party solutions such as nvm and nvs do solve this problem, however, it's my opinion that Node should have a built in updater to ultimately resolve the issue.

What is the feature you are proposing to solve the problem?

Adding an built in updater.

All Node.js releases are already uploaded to the Node.js website in a way that can be downloaded in an automated way (see https://nodejs.org/dist/), so, no changes need to be done in that part.

There are definitely specifics that need to be worked out, but, here's a general overview of how I propose this working:

• Change default installation paths for better management of versions.
  • For Windows, C:\Program Files\node\vX.X.X
  • For Unix systems, /usr/local/node/versions/vX.X.X. /usr/local/bin/node being a symlink to the current version
  • I honestly just came up with these paths with little thought, if there are any paths that would work better please let me know
  • Regardless of where the executable is placed, this feature should work as long as the executable's parent folder is named whatever version of Node it is
    • E.g. some-dir/node.exe shouldn't allow for any of the cli arguments described below to be ran while v18.0.0/node.exe should
  • Due to this specifically it's my opinion that this feature should not be backported
  • This feature should not be included in any unofficial builds since it's more than likely the binary won't be in the correct installation path
• An update is triggered via the --update=[release branch/vX.X.X] cli argument
  • User can specify which release branch they want to update to or a specific version they wish to download
    • A user can downgrade using this as well if they wish, however, I think the user shouldn't be able to downgrade to a version that doesn't have this feature to avoid them getting stuck there
    • If a user downgrades to a version that's EOL, they should be warned
  • Accepted release branches:
    • latest - Absolute latest release. This is the default if no value to the argument is supplied.
    • lts - Latest LTS release
    • minor - Update to the latest minor release on the same major
    • patch - Update to the latest patch release on the same major and minor
  • I'd imagine administrator permissions are needed to run for file system access
  • If the user wishes, they can change all urls that can possibly be used through more cli arguments
• User can switch between installed versions with --switch-version=<vX.X.X>
  • We could warn the user if the version they switch to is EOL, however, I don't think that should happen since it would require making an unneccessary remote call
• User can uninstall a version they're currently not using with --uninstall=<vX.X.X>

I opened this issue to have a discussion on this proposal and get feedback from the community.
I am willing to work on this feature given that this is something the community wants and TSC approves, as I know this by far not a trival feature to add.

What alternatives have you considered?

• Something similar to the proposal above minus the version mangement and only the capability to upgrade/downgrade whatever version you're on
• Bundling nvm and nvs with Node
  • Absolutely the simplest approach. Many use either of the two or both already
  • Shouldn't be too hard to do and it shouldn't be a breaking change
  • Needs approval from their maintainers?
• I haven't been able to find any other proposals for something among the lines of this

[Trott]

Ref: #44942

[Trott]

A big challenge is that there are a lot of different ways people install Node.js and a feature like this might be error-prone in the current ecosystem. But that's a statement about the current state of affairs and speculation on the impact, not necessarily an insurmountable issue.

[Trott]

@nodejs/version-management You folks would probably have a lot to say here.

[ljharb]

Indeed, the path to solve this is very long and complex - and the first step remains to design standard installation locations that are used by all the popular node installers and version managers, so that once node is installed by anyone, any version manager or installer can work with it.

See nodejs/version-management#3 for that effort - it'd be great if someone wants to volunteer time for it.

[coreybutler]

I would be pretty firmly against this. I envision it dividing the community and reducing choices people are already accustomed to and like.

Users would be forced to make a version management choice. You cannot have multiple active versions of Node installed at the same time because the PATH always yields whichever binary comes first in the list. Version managers work around this using shims and managed symlinks. Unless Node wants to start using a shim/symlink, users would have to choose this approach OR a version manager.

There's also the dependency problem. What happens to global modules when an upgrade occurs? For Windows users, upgrading native dependencies automatically can be a problem, especially if a user has upgraded/downgraded/removed native libraries since the module was compiled (like moving from Visual Studio 2017 to 2019). To me, it feels like the lines between npm and Node start to get blurred here... not to mention yarn/pnpm/etc. Perhaps it's no more than it already is, but managing npm is a different beast from simple version management.

I wouldn't bundle a version manager either because it's making an opinionated choice for users. nvm-windows and nvm-sh have some similarities, but plenty of differences. The code bases are completely different (Go vs bash), primarily because Windows is so different. Each of the version managers vary quite a bit.

Bottom line, I'm all for standardization, but I worry this would be making too many choices for users.

[flakey5]

A big challenge is that there are a lot of different ways people install Node.js and a feature like this might be error-prone in the current ecosystem

What do you think would have to change in order for something like this to be less of a flaky addition then?

See nodejs/version-management#3 for that effort - it'd be great if someone wants to volunteer time for it.

What all still needs to be done in this regard?

Unless Node wants to start using a shim/symlink, users would have to choose this approach OR a version manager.

Using symlinks is pretty much what would have to happen. As long as the symlink is also standardized with the installation path, users should still be able to use whatever version manager they want.

What happens to global modules when an upgrade occurs?

That's something I'm not so sure on. I would like to get others' input on this, but, it could just be that that falls outside of the scope of what this covers since it's about modules rather than Node itself.

I wouldn't bundle a version manager either because it's making an opinionated choice for users.

That's valid, in my opinion bundling any third party version manager shouldn't be the case but it was still something to take into consideration.

[Trott]

What do you think would have to change in order for something like this to be less of a flaky addition then?

I imagine resolving the standard-location-for-install issue (nodejs/version-management#3) would go a long way to resolving the concern.

[shadowspawn]

What happens to global modules when an upgrade occurs?

I think the global modules changing when changing node versions is one of the big differences between an isolated version approach and updating the version in place. I notice multiple node version managers which support isolated global modules also offer help with migrating global modules.

• nvs Global modules
• nvm Migrating Global Packages While Installing
• nvm Default Global Packages From File While Installing

And I see open issues against node version managers which do not help with global packages (e.g. fnm), but the utilities are still poplar so it isn't a show-stopper.

[shadowspawn]

For Unix systems, /usr/bin/node/vX.X.X

1. I personally don't expect to find directories in the bin folder. I don't currently have any in /usr/bin or /usr/local/bin

2. I think of /usr/bin as the system managed location. On Mac, third party applications usually install to /usr/local/bin. For example node and deno and docker. (/opt is another location, but on Mac I have only noticed Homebrew using it when running on Apple Silicon, amd64.)

More concretely, the Filesystem Hierarchy Standard says

The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.

Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.

3. I am not sure where the version directory should go. n caches by default to /usr/local/n/versions. I have looked a couple of times for a better location, but didn't find a compelling enough location to change legacy usage.

4. There is a fancy system of environment variables for unix systems that I (rarely) see users ask for support for locating directories. XDG Base Directory Specification

[tniessen]

Third party solutions such as nvm and nvs do solve this problem, however, it's my opinion that Node should have a built in updater to ultimately resolve the issue.

Why? What major benefit does that provide?

I usually install nvm in dev environments and don't bother installing node from any other source. Then, every node version is just one command away (and doesn't require root privileges). In production environments, docker containers, etc., there is no need to manually switch between versions.

Due to this specifically it's my opinion that this feature should not be backported

Not only would this only allow installing and switching between node versions that implement this feature, but it could also cause major problems if some node version had a bug related to this feature. With external tools, such as nvm, this is not a big concern; if there is a bug in nvm, it is most likely consistent across node versions and can be fixed for all node versions simultaneously.

This feature should not be included in any unofficial builds since it's more than likely the binary won't be in the correct installation path

I assume that you'd want to disable this feature for node binaries installed through nvm, nvs, apt, snap, pamac, etc.

What distribution channels would this be enabled for? AFAIK there is no official "installer" for Linux, and the Windows installer does not allow side-by-side installations.

[jasonkarns]

@shadowspawn

I think the global modules changing when changing node versions is one of the big differences between an isolated version approach and updating the version in place.

Nodenv also supports default global modules through a plugin: https://github.com/nodenv/nodenv-default-packages

[flakey5]

I am not sure where the version directory should go. n caches by default to /usr/local/n/versions. I have looked a couple of times for a better location, but didn't find a compelling enough location to change legacy usage.

Ah I see, so something among the lines of /usr/local/bin/node being a symlink to a path like /usr/local/node/versions/vX.X.X/node would be more appropriate?

There is a fancy system of environment variables for unix systems that I (rarely) see users ask for support for locating directories.

I definitely think that's something to take into consideration in the impl if there are enough users of it. Even if there aren't it doesn't look like it'd add much overhead when deciding where the installation path is

Why? What major benefit does that provide?

It removes the need to install any third party version managers. In production environments it would not make much of a difference, this feature would purely just be for the developer

(and doesn't require root privileges)

Admin privileges might only be necessary on Windows when modifying data within the C:\Program Data directory. Still need to confirm that however.

it could also cause major problems if some node version had a bug related to this feature

That is definitely a possibility, the only real solution for that is to have tests in place whether that be people manually doing so or automating it in some way.

I assume that you'd want to disable this feature for node binaries installed through nvm, nvs, apt, snap, pamac, etc.

I think the only way to do this would be by checking whatever path the Node binary is in as part of the startup since afaik they all get it from the officially released builds on Node's website. Plus, given that the installation paths have been standardized and adopted as @ljharb was talking about, I don't really see a purpose in that extra effort and would be against it. What I meant by unofficial builds were pre-released versions or those built in a dev environment

[bnoordhuis]

I imagine this is inspired by deno's auto-update feature?

One key difference between deno and node is that deno is a single binary and node isn't. Most people don't use just node, they use node+npm.

@coreybutler briefly touched on it already but I want to stress: auto-updating npm is not at all trivial. No one likes a wall of text so I'm not going to enumerate all possible failure modes but they're numerous.

[flakey5]

I imagine this is inspired by deno's auto-update feature?

Nope

auto-updating npm is not at all trivial. No one likes a wall of text so I'm not going to enumerate all possible failure modes but they're numerous.

It still is possible however, and that's another reason why I opened this issue in order to discuss and minimize any possible issues with an implementation

[tniessen]

One key difference between deno and node is that deno is a single binary and node isn't. Most people don't use just node, they use node+npm.

AFAIK, deno also does not have multiple active release lines that users might want to switch between frequently.

User can switch between installed versions with --switch-version=<vX.X.X>

Using symlinks is pretty much what would have to happen. As long as the symlink is also standardized with the installation path, users should still be able to use whatever version manager they want.

Ah I see, so something among the lines of /usr/bin/node being a symlink to a path like /usr/local/node/versions/vX.X.X/node would be more appropriate?

Does this mean that this version manager would only work on a per-system basis (or maybe per-user), but not per-shell? That would be considerably less than what nvm supports. If I want to see if my package, that I wrote for node 19, works in node 16, I don't want to switch node back to version 16 for the entire system.

It removes the need to install any third party version managers.

On the other hand, third-party version managers (that are known to work very well) remove the need to install node from any of the less convenient distribution channels (downloading from nodejs.org, apt, pamac, snap, ...).

I assume that you'd want to disable this feature for node binaries installed through nvm, nvs, apt, snap, pamac, etc.

I think the only way to do this would be by checking whatever path the Node binary is in as part of the startup since afaik they all get it from the officially released builds on Node's website. Plus, given that the installation paths have been standardized and adopted as @ljharb was talking about, I don't really see a purpose in that extra effort and would be against it.

Do package managers like snap even support self-updating packages? For apt, it's probably possible to have some sort of self-updating process, and maybe it won't interfere with dpkg and its uninstall procedures.

My understanding of your proposal thus far is that this would not work if I just downloaded node from the website and placed it anywhere. It likely also won't work with package managers such as snap, and makes little sense in containerized environments such as docker. When installing through package managers such as apt or pamac, I have to hope that node's self-update process won't break the package manager's update, repair, or uninstall procedures for packages.

[shadowspawn]

When installing through package managers such as apt or pamac, I have to hope that node's self-update process won't break the package manager's update, repair, or uninstall procedures for packages.

Yes, but my expectation is that the self-update would decline to run on a conventionally installed node, because the folder hierarchy would not show it is expecting version changes. (Not sure if that behaviour is included in your "would not work".)

Reference: #46409 (comment)

Regardless of where the executable is placed, this feature should work as long as the executable's parent folder is named whatever version of Node it is

• Regardless of where the executable is placed, this feature should work as long as the executable's parent folder is named whatever version of Node it is

  • E.g. some-dir/node.exe shouldn't allow for any of the cli arguments described below to be ran while v18.0.0/node.exe should

[shadowspawn]

Does this mean that this version manager would only work on a per-system basis (or maybe per-user), but not per-shell? That would be considerably less than what nvm supports. If I want to see if my package, that I wrote for node 19, works in node 16, I don't want to switch node back to version 16 for the entire system.

For comparison, the usual way of using n is to update the system or user installed version of node. So similar to the proposed update mechanism.

To allow per shell usage, n run 10.2.1 script.js will spawn the target version of node, and n exec 10.2.1 some-command will spawn a shell to run the command with the PATH altered to include the target version of node (et al).

[bnoordhuis]

self-update would decline to run on a conventionally installed node, because the folder hierarchy would not show it is expecting version changes

There are too many ways for such heuristics to break down, I would say, both in the false positive and false negative sense.

[flakey5]

Does this mean that this version manager would only work on a per-system basis (or maybe per-user), but not per-shell?

Yes, per shell could be something to explore but as the proposal stands right now it wouldn't be.

Yes, but my expectation is that the self-update would decline to run on a conventionally installed node, because the folder hierarchy would not show it is expecting version changes. (Not sure if that behaviour is included in your "would not work".)

Yeah it would just decline to run and print something to the console saying it couldn't run due to where it's located

[tniessen]

my expectation is that the self-update would decline to run on a conventionally installed node

So how would I install node such that version management works? This is easy enough through third-party tools, but how do you envision this to work in your proposed framework?

[flakey5]

So how would I install node such that version management works? This is easy enough through third-party tools, but how do you envision this to work in your proposed framework?

For Windows and Mac it'd stay the same, users would just use the installers. For Linux, I honestly don't really know. I know in Debian-based Linux distros you can run a .deb file which is a possibility. Arch or Fedora based systems may have something similar?

[flakey5]

So, generally speaking, is this something that the community and the TSC are interested in pursuing?

[tniessen]

So, generally speaking, is this something that the community and the TSC are interested in pursuing?

@flakey5 I think this discussion has been very vague so far, and a much more concrete proposal is needed to make any progress. Most importantly, it is still unclear to me how this is supposed to work with the various Linux distribution channels. (For example, you mentioned .deb files in your last comment, but if and how dpkg would interact with node's own version management in that case is unclear.)

Also, the various discussions in nodejs/version-management and this issue that was effectively blocked by the version management group might be of interest.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[bnoordhuis]

I'll close this because I don't think there's consensus or a clear path forward, and also to discourage further bump comments.