Adding a Version Checker #44942
Description
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-updatecli argument and you set it to what release branch you follow.- This would work like
--versionwhere 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 runningv16.x.xwill get notified forv18.x.xbut not forv17.x.xsince it's not LTS--check-update=same- Follows whatever major you are on and ignores any updates not pertaining to the major. Ex/ user runningv17.x.xwill get notified forv17.y.ybut not forv18.z.zsince 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-updateand nothing else), this is what it defaults to.
- This would work like
--version-check-urlcli argument in case the user would like to override the url it requests for whatever reason- New updates presented to user via
process.emitWarningwith a message such asNew version available! vX.X.X (current) -> vY.Y.Y (new). Could also add a note if it's a security release likeNew 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
Activity
flakey5 commentedon Oct 9, 2022
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 commentedon Oct 9, 2022
@nodejs/version-management Is this something any of the version managers (
nvm,n, etc.) implement already?ljharb commentedon Oct 9, 2022
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 commentedon Oct 9, 2022
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 commentedon Oct 9, 2022
I might not mind it opt-in only, but also I'm not sure it couldn't then be an npm module.
coreybutler commentedon Oct 9, 2022
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 commentedon Oct 9, 2022
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 commentedon Oct 10, 2022
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 nodeor similar automatically every time, and it’ll just be a noop if there’s no update.jasnell commentedon Oct 10, 2022
The check that @flakey5 is proposing would be opt in only and does nothing more than notify if a newer version is available.
@ljharb:
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:
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 commentedon Oct 10, 2022
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 commentedon Oct 10, 2022
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 commentedon Oct 10, 2022
Sure, of course we can. However, args parsing constitutes extremely high usage on npm; does a node update notifier?
jasnell commentedon Oct 10, 2022
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 commentedon Oct 10, 2022
Vendoring in
semvercould be increase the size of the binary, do we have a simple way to measure that?56 remaining items
ljharb commentedon Oct 26, 2022
"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 commentedon Oct 26, 2022
I think having a
nodecommand to check for an update which users then need to follow up with a separatenornvmorbrewor 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
nodeto 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 commentedon Oct 26, 2022
@GeoffreyBooth this is one of the points I was referring to.
What problem are solving with this, and to who?
RaisinTen commentedon Oct 27, 2022
@jasnell
Thanks for explaining! 🙏
As I mentioned in #44942 (comment) (second part) and #44942 (comment) (
Version checkerpart), I think this is gonna do the opposite actually.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?
Are the other uses mentioned in this issue? Could you please share a link? If you're referring to there being a duplication of
semverindeps/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).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 commentedon Oct 28, 2022
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 commentedon Oct 31, 2022
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 commentedon Nov 2, 2022
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 commentedon Nov 2, 2022
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 commentedon Nov 2, 2022
@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 commentedon Nov 2, 2022
I personally see the points:
flakey5 commentedon Nov 2, 2022
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 commentedon Nov 2, 2022
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 commentedon Nov 2, 2022
Thank you all as well for your time!