Repository navigation
Adding a Version Checker #44942
Description
Activity
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.
@nodejs/version-management Is this something any of the version managers (
nvm,n, etc.) implement already?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.
Reacted by Ruy AdornoRecommending 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.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.
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.
Reacted by Jordan Harband, Claudio Wunder and Ruy AdornoThis 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.
Reacted by Corey Butler and Tierney CyrenThis 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.The check that @flakey5 is proposing would be opt in only and does nothing more than notify if a newer version is available.
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.
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.
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.
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.
Sure, of course we can. However, args parsing constitutes extremely high usage on npm; does a node update notifier?
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.
Vendoring in
semvercould be increase the size of the binary, do we have a simple way to measure that?56 remaining items
"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.
Reacted by Claudio WunderI 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.Reacted by Claudio Wunder@GeoffreyBooth this is one of the points I was referring to.
What problem are solving with this, and to who?
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 checkerpart), 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
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).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.
Reacted by Jordan HarbandOne 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."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.
Reacted by Claudio Wunder, Jordan Harband, Marcel Klehr and Darshan SenWould 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.
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.
Reacted by Corey Butler@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.
I personally see the points:
- A network call seems not feasable for now
- 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
- 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
- An opt-in with e.g., a flag or env is a possibility
- An auto-update feature is not something for now but it might be something to look into later on again
Reacted by Jordan HarbandI 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.
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!
Reacted by Darshan Sen, James M Snell, Corey Butler, flakey5, Ruben Bridgewater, Geoffrey Booth, Jordan Harband, Ruy Adorno and Patrick LeiserReacted by Gireesh Punathil, Ruy Adorno and Jean BurellierThank you all as well for your time!
Reacted by Claudio Wunder, Darshan Sen, Antoine du Hamel, Jordan Harband, Gireesh Punathil, Ruy Adorno and Aviv Keller
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.
--check-updatecli argument and you set it to what release branch you follow.--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.--version-check-urlcli argument in case the user would like to override the url it requests for whatever reasonprocess.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).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