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?

[ljharb]

If we could bring in semver and expose it that’d pay for itself a millionfold, so if this is the catalyst for that, go for It :-)

(fwiw on Twitter you don’t have to wait for anything; you can get mobile notifications on a user that polls nodejs.org/dist)

[flakey5]

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.

That is a good point. I'll update it to only work off of cli arguments to fix that.

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

The source files for semver are only ~57KB and the total size of the module is ~86KB

[aduh95]

If we could bring in semver and expose it that’d pay for itself a millionfold, so if this is the catalyst for that, go for It :-)

We would need to make sure semver maintainers are OK with that (not every one is happy to see their code being vendored in), but yeah that's a good point.

[jasnell]

We should split those decisions re: semver. It's perfectly fine for us to vendor in the dependency for use here. Choosing whether to expose it as an API is a different question entirely that should be discussed separately. But yes, this check can be a path to getting there.

[shadowspawn]

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

n does not include a version checker against the installed node version, but does have convenience methods for displaying the latest current and LTS versions (and a general purpose ls-remote). e.g.

$ n --lts
16.17.1

This does sometimes get spammed while people are waiting for an update to become available. 😄

[targos]

+1 if node --check-update defaults to same.

[anonrig]

Out of topic but due to the example implementation: Is there an open discussion on adding semver like feature inside node? preferably inside node:util?

[jasnell]

Out of topic but due to the example implementation: Is there an open discussion on adding semver like feature inside node? preferably inside node:util?

That would be possible, yes, but it's a separate discussion that we should open a separate thread for.

[targos]

@anonrig there's a discussion here: nodejs/tooling#146

[bnb]

The OP says opt-in only. I see that was an edit, but IMO it's a good and non-controversial edit. I'm +1 this since it's explicitly opt-in.

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

FWIW semver is already included in Node.js via being included in npm, so if we added semver to Node.js core first, npm in Node.js could use Node.js's semver and we'd theoretically see zero bundle size change.

We would need to make sure semver maintainers are OK with that (not every one is happy to see their code being vendored in), but yeah that's a good point.

They are, they literally asked us to. It's the npm team. I don't want to speak for them, obviously, but my understanding is that they'd be fine.

(I'll cease the semver talk here, just wanted to address these open questions)

(fwiw on Twitter you don’t have to wait for anything; you can get mobile notifications on a user that polls nodejs.org/dist)

unfortunately this user died when I quit Microsoft. Personal-time project that's not affiliated with Node.js that I'm slowly working rewriting on when I have energy :)

[bnb]

One small note: I'd change --version-checker-url to --version-check-url to have check be consistent with the rest of the commands

[mscdex]

FWIW semver is already included in Node.js via being included in npm, so if we added semver to Node.js core first, npm in Node.js could use Node.js's semver and we'd theoretically see zero bundle size change.

Except you'd need to support people running newer versions of npm on older versions of node. That means having to keep two copies around for some time.

[flakey5]

That means having to keep two copies around for some time.

The total of both copies would be under 200kb, so it wouldn't really be noticeable imo.

Also, as of now the current edit represents the most up-to-date proposal. I'll start working on the pr today or within the next new days. With some thought on it I do think vendoring semver would help tremendously and, from what I can tell, it is wanted by others as well. I'll probably vendor it in a separate pr and when that lands I'll open the one for the version checker just for neatness.

[jasnell]

@flakey5 :

This would work like --version where it simply checks for an update and then exits.
--check-update=off - Does nothing. Just for explicitly turning it off.

Since this will immediately exit after performing the check, we don't actually need --check-update=off.

--version-check-url

I'd suggest renaming this to --check-update-url so that the naming is consistent with the other flag.

[mcollina]

I would recommend a bit more nuances on the rules above.

1. recommend an update to the top-of-the-line release, e.g. from v18.10.0 to v18.11.0 (as the time of writing).
2. recommend an update to the latest LTS release in case the current Node.js runtime is out of support.
3. signal any security release that have been missed

[bnb]

I wonder if it wouldn't be easier to implement this feature in Corepack rather than Node.js:

IMO -1 on a version checking tool going into corepack. Such functionality is outside the expressed scope of that tool.

It's also what pkgjs/nv uses.

I would not recommend looking at pkgjs/nv as a good source of truth - I tried using it and it fundamentally doesn't work as advertised - I had to make my own tooling to get that functionality.

The goal is to ship npm through Corepack in the (near?) future.

IMO this is an especially bad goal that will hurt end-users, but this probably isn't the place for that discussion.

It means it would only benefit Corepack users, but it wouldn't change anything for you if you don't use Corepack. So no, people wouldn't need to use Corepack.

Right, and the goal of this proposal is to benefit Node.js users. IMO if this is the goal of Corepack as a proposed solution, it's a non-starter - I believe that @flakey5 is taking the correct approach by proposing it for Node.js core as a way to help the broader ecosystem ensure they're on the latest version of Node.js, regardless of their package manager tooling.

Should the Node.js binary itself, via an opt in command-line option, be able to check to see if there is an updated version available?

IMO yes +1.

I do consider this proposed feature as improving overall Developer Experience (point 4 for why a feature should be added) in Node.js in much the same way that adding other things can be done by others tools does (e.g. a test runner didn't need to be added, an args parser didn't need to be added).

+1.

Also, if we expect third party tools to provide this functionality, they could actually use this mechanism to make their implementations easier and more consistent with each other. I don't expect everyone to agree with that argument, but it's something I consider useful.

+1. If additionally provided as an API that can be called from user-land, tools like corepack, npm, yarn, and whatever replaces all of those could hook into this and provide opinionated DX, where the under-the-hood implementation doesn't matter to the user but infra/IT folks could have reasonable and consistent control regardless of the tool (for example if they want to block such requests from happening in prod systems + alert when they're attempted). IMO that'd be a massive benefit to a core implementation of this.

[Trott]

The goal is to ship npm through Corepack in the (near?) future.

I'm unaware of consensus on that, and judging from the reaction of others here, I'm not alone. At a minimum, this would require some more conversation.

ANYWAY, back to the original question or something close to it:

Would it be good for Node.js to have an opt-in configuration of some kind that will let you know, maybe once a week or so, if you are running a version of Node.js that is either EOL or has a newer version available with the same major release number?

My answer is: That would be a great experimental feature to add. Node.js doesn't need it, but I think it would help a lot of users, and it's kinda sorta expected for a lot of things these days. On the other hand, that tends to be something that shows up in tools more than runtimes. But still, as an opt-in experimental feature, I like that experiment. It could be an npm module we publish officially, and I wouldn't mind that either if that's the preferred route.

[GeoffreyBooth]

Are there any other similar projects that offer a similar feature? Like Deno, or Python or Go, or any command-line runtimes or tools?

deno upgrade --dry-run

BUN_DRY_RUN=1 bun upgrade

When I tried to think of similar features in other tools, the only things I could come up with are auto-updating apps like Chrome; and npm‘s prompt that a new version is available. I can’t think of any other command-line tool, much less runtime (for any language) that has a command just for checking if an update is available and reporting that answer; it either has an “update” command or an automatic prompt that the user should update. This seems to me to hint that an opt-in command to proactively check for an update wouldn’t be very useful.

What if instead of being a command, we followed the example of npm and just printed a message on startup periodically if an update was available? And we need to somehow try to only print this message when we think there’s a user to see it, and not on servers running in the cloud. Maybe we only print the message when the user starts the REPL, for example.

[ljharb]

npm's update notifier has been the source of a very large number of complaints, and while I don't think there's a concerted effort yet to remove it, I'd be surprised if the npm team was particularly attached to keeping it.

[ovflowd]

This seems to me to hint that an opt-in command to proactively check for an update wouldn’t be very useful.

Agreed.

What if instead of being a command, we followed the example of npm and just printed a message on startup periodically if an update was available? And we need to somehow try to only print this message when we think there’s a user to see it, and not on servers running in the cloud.

Please let's not, this will increase the cold boot time of node and be a huge source of complaints.

Maybe we only print the message when the user starts the REPL, for example.

It would then be a very useless feature.

[ovflowd]

It truly feels we all have very different opinions on how to do this. Yet it seems that other JavaScript runtimes do have built-in update commands. But no commands for checking if an update is available (besides of running the update command with DRY_RUN).

This could indicate that adding such a command on node doesn't seem a good idea. I also don't think many people will be aware of it; even fewer people might adopt it.

Hence, adopting a solution like also telling the user when a new version of node is available through NPM feels like a good solution, as NPM already tells when there are new updates available for NPM.

Otherwise, the website is a good source for notifying the user upfront with 0 interaction.

Because either adding it on node or npm won't result in a "notification", as @RaisinTen mentioned. It is a "reactive" prompt. You're asking to check for updates, which will tell you if there are any. For me, a notification is something that "gets pushed" and not something I need to manually "check".

And what is the actual goal? How does adding this to node helps our user base? Why would our user base regularly want to run a "check for update" command if most of the developers (probably) "intend" to stay on their same major version for obvious reasons, as when they're developing applications, they would likely like to stay on a specific version?

Of course, that's not the case for minor and patch versions, as they include bug fixes, security patches and more.

But if the reason for being "notified" is for such updates (because I believe that's the use case I'm most interested in), it should (definitely) be something in the line with "I want to be notified" as soon as it is out. And not something I need to remember to run every once in a while.

Hence why I originally suggested npm... Because we often run npm for adding, removing or updating dependencies.

But honestly, it feels like the best place for a "notify me for an update of node.js" on our website.

[jasnell]

@ovflowd :

Yet it seems that other JavaScript runtimes do have built-in update commands. But no commands for checking if an update is available (besides of running the update command with DRY_RUN).

hmm... I read this as: They don't have commands to check for an update except the commands they have that check for an update.

The "dry run" options are specifically provided for exactly this kind of purpose. It's just implemented in a different way.

This could indicate that adding such a command on node doesn't seem a good idea.

I don't understand how you can draw this conclusion. Other tools do in fact have mechanisms for checking to see if there is an updated version, the fact that those might be tied to additional functionality for actually performing the update is secondary in my opinion.

... won't result in a "notification", as @RaisinTen mentioned. It is a "reactive" prompt ...

This just feels like quibbling over a definition. Very well, let's not call it a notification and let's not rabbit hole any further on whether this feature proposal is actually a "notification" or not. It's an explicit check to see if there is an updated version.

...Why would our user base regularly want to run a "check for update" command

Speaking for myself, I regularly use node on multiple systems with potentially a broad range of Node.js versions deployed on them. In every case, I always check node -v as one of the first steps whenever I run on a new system or a system I haven't accessed in a while. Personally I always keep track mentally of what the current release line is so I can tell immediately from the version output if it is out of date but I do not suspect most users have that awareness. For that case, switching from node -v (which only tells me the current version) to node --version-check (which would tell me the current version and the next version) gives me more useful information that saves me from having to take a separate step to go check out the website.

[ovflowd]

I don't understand how you can draw this conclusion. Other tools do in fact have mechanisms for checking to see if there is an updated version, the fact that those might be tied to additional functionality for actually performing the update is secondary in my opinion.

I believe you misunderstood what I meant. Either we add a command that allows node to update itself, or just having a command just to say "hey there's an update" feels, for me, pointless, as I can just do the same on the web, or through nvm. (Or any similar tool)

This just feels like quibbling over a definition.

It is not. Either it is a "notification" or is the user manually checking for an update. That's not what a notification is IMHO 😅

Personally I always keep track mentally of what the current release line is so I can tell immediately from the version output if it is out of date but I do not suspect most users have that awareness.

I don't think the average user is aware of this. Which is something many pointed here out. The average user is not well-versed enough to understand these technicalities. Not saying they could, but then we're talking about user re-education.

(which would tell me the current version and the next version) gives me more useful information that saves me from having to take a separate step to go check out the website.

You still need to go to a website to download a newer version of node or use nvm (or another similar tool). How does this (adding version check on node) reduces the effort?

Isn't then just easier to altogether just ask nvm (or any other node version manager) to update the version to the latest minor?

---

Again, I'm not opposed to this change; just really trying to ponder what are the actual benefits of doing just a version checker directly on node itself and for which audience we're making this change?

[sheplu]

I do think the idea is really interesting and can be useful to improve the DX.

From what I see, the current way to "solve this issue" would be to

• run node -v
• go check the version on nodejs.org
• do some update (or not)

The proposed version would add a command to keep everything in the terminal

• run node -v
• check the version with node --check-version
• do some update (or not)

My takes on that would be that people not looking from time to time on the website to see new release won't check the version using the command line with another new command.

But that could be interesting to still add the functionality. Maybe with some minor (?) changes

• do we need the three flags ? don't you think that people will just use the default value and think they are up to date while in fact they are just on a branch without new release (same being the default value and current seems to be the only value where the user will be notified of an existing new version)
• could it be better to always output the three value latest version of the current branch | latest lts | latest version (I am not even sure it is interesting to keep the latest version)
• do we want to add that when someone execute node -v ? this would be the perfect timing to inform someone that they are currently on a old / deprecated branch or just are missing some fixes. But doing that would change and break the current output of the command.
• not really sure of the use case of --version-check-url this seems a bit far fetched thinking that company blocking http calls will maintain a local version of the page
• if we don't want to change the current version output, maybe the output of the command could be used after npm install or npm audit (just throwing that here)

Also, I don't think this would be a great idea to have a 'notification' when you run node, or every week or something else. This could be a bit spammy or on the other hand just be completely hidden by systems (and so not being useful)

[ljharb]

"doing an update" is complex, given that not everyone has permissions to do so; not every environment will want to permit doing so even if the user has the permissions (think an infra team wanting to prevent devs from footguns); not everyone will have the disk space or the internet bandwith to do so successfully, so error recovery will be very critical; without certificate pinning, the nodejs.org connection could be intercepted, which could lead to security issues, and bundling certificates into node will mean that updating breaks in the future when those certs expire; etc.

[GeoffreyBooth]

I think having a node command to check for an update which users then need to follow up with a separate n or nvm or brew or other version manager command to perform the update is potentially confusing. Can anyone point to even one example of a command-line tool/runtime/program that provides an API for checking for an available update, without also providing a way to upgrade to that new version?

I can understand adding this now if we intend to add the ability for node to update itself as a later improvement, but it seems like many people are opposed to such functionality; so I’m hesitant to add what feels like an incomplete feature.

[ovflowd]

@GeoffreyBooth this is one of the points I was referring to.

What problem are solving with this, and to who?

[RaisinTen]

@jasnell

We are apparently working with two different definitions of the word "notifying" in mind. What @flakey5 is proposing is an opt in version check, "Is there a newer Node.js version than what I'm running right now? Yes or No". That's what he and I both mean when we say "notifying users" and this proposal exactly addresses that.

Thanks for explaining! 🙏

I do consider this proposed feature as improving overall Developer Experience (point 4 for why a feature should be added) in Node.js in much the same way that adding other things can be done by others tools does (e.g. a test runner didn't need to be added, an args parser didn't need to be added).

As I mentioned in #44942 (comment) (second part) and #44942 (comment) (Version checker part), I think this is gonna do the opposite actually.

I also consider this proposed feature as providing "functionality that can be expected to solve at least one common use case Node.js users face." (point 5 for why a feature should be added).

How is this a common use case? Are there other issues asking for this feature? AFAICT, this feature can be implemented in userland but there is no such implementation maybe because this feature is not a common use case?

Given the other conversations around potential uses of a vendored semver module, this proposal also potentially addresses "part or all of the component will also be re-used or duplicated in core." (point 7 for why a feature should be added).

Are the other uses mentioned in this issue? Could you please share a link? If you're referring to there being a duplication of semver in deps/npm/node_modules/semver, I wonder why we are not using that directly during the esbuild step in #45127. No need to discuss that here, I'll ask that in the PR (asked - https://github.com/nodejs/node/pull/45127/files#r1006877559).

Also, if we expect third party tools to provide this functionality, they could actually use this mechanism to make their implementations easier and more consistent with each other. I don't expect everyone to agree with that argument, but it's something I consider useful.

Why would we expect that? I don't think any third part tool has implemented that. Sure, if it were to be implemented by a lot of third party tools, I can see your point but the fact here is that none of the third part tools have implemented this feature in spite of being capable of doing so.

[Trott]

One use case might be to have people run node --check-updates (or whatever) when reporting a bug. It could be in the GitHub issue template/form. The output would tell people right away "Hey, you're running an unsupported version" vs. "There's an update available. Install that and see if it fixes your problem." vs. "You are running the latest supported version and should go ahead and report this bug."

[GeoffreyBooth]

Personally I feel like if we can’t find any examples out there of CLI tools with a similar feature, this is likely to be confusing to users and therefore something that we shouldn’t add. It makes a lot of sense to me as a component of an “autoupdate” feature, or even a user-triggered update feature, but if we’re not planning on adding such features then this “version check” on its own feels a bit like a loose end. Before going forward with “version check” on its own I would like to see examples of such a standalone feature elsewhere, so that I can see how the UX makes sense in similar tools; or a plan for what this feature would support as some kind of larger goal such as an “update” feature.

[joyeecheung]

Would it be possible for the existing Node.js version managers to use this feature? What would the interop story look like? Would they still need to implement a similar check themselves?

I saw that there was a user survey in 2021, but couldn't find the data. Would be nice if we can check how people get their Node.js installation in the first place to decide which approach would benefit the majority of our users.

[ljharb]

A node version manager either has to bundle its own copy of node - which one or two do - or, more commonly, it wouldn’t ever be able to use a feature built into node, since it couldn’t rely on that feature, or node itself, existing.

[jasnell]

@flakey5 ... This was discussed on the TSC call and it's looking like there is no consensus currently on adding this feature. There was a good amount of discussion on the topic if you want to review the TSC call recording, but otherwise I think the current status here is that this is not likely to land at all.

[BridgeAR]

I personally see the points:

1. A network call seems not feasable for now
2. Notifying the users as soon as the version passes it's End-of-life date by printing to the terminal during startup is a possibility
3. Notifying the users as soon as the version passes it's Maintenance Start date by printing to the terminal while starting the REPL is a possibility
4. An opt-in with e.g., a flag or env is a possibility
5. An auto-update feature is not something for now but it might be something to look into later on again

[flakey5]

I think the current status here is that this is not likely to land at all.

Alrighty, well, I think I'll close the issue now then. I'll keep the semver pr open since there are other use cases for it but I'll remove the reference to this issue.

[ovflowd]

Alrighty, well, I think I'll close the issue now then. I'll keep the semver pr open since there are other use cases for it but I'll remove the reference to this issue.

I just wanted to say (and I think everybody here agrees), @flakey5, is that we really appreciate your engagement and your contribution! Whilst this will not land for now, we do appreciate the effort you put into this.

And I definitely welcome you to contribute with other Issues or things you believe will benefit the broader Node community. Ideas like these (spontaneous and cool) drive the project :)

Stay safe!

[flakey5]

Thank you all as well for your time!