Adding a Version Checker

[flakey5]

What is the problem this feature will solve?

Node does not have a version checker that lets the user know if they're on an outdated version. In my opinion, having one would absolutely improve QOL and would help notifying users of new versions.

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

Adding a opt-in version checker. I propose it as opt-in because of potential privacy concerns and this could be considered a breaking change due to the additional overhead. Also, I believe it would be best to implement it on the Javascript side just for simplicity.

The Node.js website already has a file that is automatically updated with every release (https://nodejs.org/dist/index.json) so all changes that need to be made are in Node core itself.

• Opt-in via --check-update cli argument and you set it to what release branch you follow.
  • This would work like --version where it simply checks for an update and then exits.
  • --check-update=current - Follows the most current release, User will get notified for any new version.
  • --check-update=lts - Follows the most recent LTS release. It will skip any odd-numbered majors and only focuses on the latest release of a LTS version. Ex/ user running v16.x.x will get notified for v18.x.x but not for v17.x.x since it's not LTS
  • --check-update=same - Follows whatever major you are on and ignores any updates not pertaining to the major. Ex/ user running v17.x.x will get notified for v17.y.y but not for v18.z.z since it's not on the same major. The name for this isn't great, if someone has a better idea please say so. If the cli argument is passed with no value (--check-update and nothing else), this is what it defaults to.
• --version-check-url cli argument in case the user would like to override the url it requests for whatever reason
• New updates presented to user via process.emitWarning with a message such as New version available! vX.X.X (current) -> vY.Y.Y (new). Could also add a note if it's a security release like New version available! vX.X.X (current) -> vY.Y.Y (new) (security release).
• Any potential errors that occur while checking the version fail silently due to the user not being in control of it and therefore can't really do anything about it

I am currently working on implementing this and created this issue to open the discussion on it and get some feedback. I have a basic experimental implementation which is linked in the reply directly below this post.

What alternatives have you considered?

No response

[flakey5]

Basic implementation: https://gist.github.com/flakey5/a719d0dc0ebdb08eaf479dc531ea13d8

Note this is just for experimenting and testing. Node coding conventions aren't followed. Errors don't fail silently for testing purposes.

[Trott]

@nodejs/version-management Is this something any of the version managers (nvm, n, etc.) implement already?

[ljharb]

Not that i know of - although npm validates engines.node.

Recommending an update is a very dangerous thing to do, and i don’t think node should be doing it.

[flakey5]

Recommending an update is a very dangerous thing to do, and i don’t think node should be doing it.

How so? In regard to breaking changes, there would be an option for a user to limit update notifications to whatever major they're currently on with NODE_UPDATE_CHECK=same.

[Trott]

Recommending an update is a very dangerous thing to do, and i don’t think node should be doing it.

I might not mind it opt-in only, but also I'm not sure it couldn't then be an npm module.

[coreybutler]

Just my $0.02: Recommendations are opinionated and should not be a part of core. This seems like something that a version manager could do, but who should be making recommendations? The "who" seems circumstantial... perhaps a team lead, a vendor, or a development standards body within an organization, etc.

[flakey5]

This might just be from my personal pov but I don't really consider this to be a recommendation in the first place. I would consider it more of just a convenient notification to inform the user that there's a new version available. If they want to update they can, otherwise they can just ignore it.

[ljharb]

This presumes every user is actually in control of their node version - if they work on a shared project, the chances they’re unilaterally responsible for updating node are slim - and there’s tons of convenient ways to get a notification when new node versions are released. In other words, I’m not sure why this is a problem worth solving.

You can always run nvm install node or similar automatically every time, and it’ll just be a noop if there’s no update.

[jasnell]

The check that @flakey5 is proposing would be opt in only and does nothing more than notify if a newer version is available.

@ljharb:

Recommending an update is a very dangerous thing to do

The notification does not recommend an update, not does it perform the update. It allows a user to easily and optionally find out if there is an update. I'm not understanding how such an optional check is "very dangerous". Sure, the user might not be entirely in control of the version they use, but that's secondary.

@Trott:

I might not mind it opt-in only, but also I'm not sure it couldn't then be an npm module.

Everything we add could be an npm module. The arg parser could have been (is) an npm module. The test runner could have been (is) an npm module. Deleting a directory recursively could have been (is) an npm module...etc. I'm finding myself less and less swayed by this line of reasoning.

[ljharb]

Fair point. it does, however, make a network call that’s presumably hardcoded to nodejs.org, in a way that the user may not be aware of due to env vars setting NODE_OPTIONS.

I’m still very unconvinced that this is a problem worth solving.

[jasnell]

The proposal does use the URL that has been well known and used by many tools for many years and provides a simple way of overriding the URL. If setting the env vars is not ideal, initiating the check and overriding the URL can be limited to command line options.

We can disagree on what problems are worth solving. I didn't really think we needed an arg parser, for instance.

[ljharb]

Sure, of course we can. However, args parsing constitutes extremely high usage on npm; does a node update notifier?

[jasnell]

We have no way of knowing really. How often do users check the website to see if there's a new version? How often do they use version managers to check? How often do they wait for notifications on Twitter? There's no way of speculating on it. In any case, I'm +1 on the change and hope it progresses. The concern over the env vars is valid and @flakey5 I recommend that this is limited to command line args to trigger the check and override the URL.

[aduh95]

Vendoring in semver could be increase the size of the binary, do we have a simple way to measure that?