Print a warning if the current major version is out of LTS

[mcollina]

As I was exploring the data of the download numbers in nodedownloads.nodeland.dev, I saw that our users do not update their installed Node.js version.

Given that we know when a LTS version will become unmaintained, we could print a message to standard output telling the user to update. This will be annoying, so maybe we should also add a way to turn it off.

cc @nodejs/lts @nodejs/tsc

[richardlau]

I can't remember where but I think there was a previous discussion along these lines which ultimately led to https://github.com/RafaelGSS/is-my-node-vulnerable.

[richardlau]

I think part of the discussion happened in #44942

[mcollina]

The previous discussion was to include a runtime check and a call to an endpoint on one of our servers. This is not a version checker as it 100% relies on builtin information.

[GeoffreyBooth]

so maybe we should also add a way to turn it off.

• I would think that src: add --disable-warning option #50661 should provide such an off switch?

[mcollina]

Yes

[tniessen]

I can't remember where but I think there was a previous discussion along these lines which ultimately led to https://github.com/RafaelGSS/is-my-node-vulnerable.

A significant difference to previous discussions is that this check would provide marginal security guarantees at best. My understanding is that there would be no warning issued to users of Node.js 20.0.0 until 2026-04-30, even though that version should likely be considered insecure long before then.

[mcollina]

A significant difference to previous discussions is that this check would provide marginal security guarantees at best.

We are not in agreement. Node.js 14 was downloaded almost 19 million times in last month (October 2023), while Node.js v12 was still downloaded 3 million times, and Node.js 10 wad downloaded 2 millions times in the same period.

Seems the users are not updating because they don't know that they need to update.

[GeoffreyBooth]

Seems the users are not updating because they don’t know that they need to update.

Well, or they know and don’t care. Add it to the backlog. I think the proper comparison isn’t against what might theoretically be possible, but rather against the status quo. Surely printing a warning that a version has reached EOL is better than not printing such a warning. Especially if the warning is somewhat stern:

Warning: Node.js 21.1.0 was scheduled to reach end-of-life on 2024-04-24. It is likely that this version of Node.js is out of date and probably contains known security vulnerabilities. Please upgrade as soon as possible.

[BethGriggs]

I'm not convinced that the majority of users are not updating because they don't know they need to. I suspect it's also made up of a mass of:

• abandoned projects/automation
• CIs running against EOL versions intentionally (IIRC @ljharb does this)
• projects where they know they're using an EOL version - but are stuck or not investing the effort to migrate to a newer version

Also, the first time users will see this warning is in April 2025 if we backport to Node.js 18, or April 2026 for Node.js 20. So, I don't think this will impact the immediate concern of people using already EOL versions.

(edit: April 2024 for Node 21.)

I do wonder if this would be better to be added to version managers rather than node itself - then it could report on historic versions.

[GeoffreyBooth]

the first time users will see this warning is in April 2025 if we backport to Node.js 18, or April 2026 for Node.js 20. So, I don’t think this will impact the immediate concern of people using already EOL versions.

And April 2024 for Node 21.

[ljharb]

LTS dates aren't even strictly adhered to; they change for all sorts of reasons. It doesn't make sense to hardcode a timebomb into node, especially one that won't even necessarily be accurate.

[GeoffreyBooth]

I do wonder if this would be better to be added to version managers rather than node itself - then it could report on historic versions.

Sure, but also, why not both?

[RafaelGSS]

How would we know that a version is out of LTS without making a remote call? A few approaches that come quickly to my mind are to have this information built-in and trust in the environment to correctly check the date and correlate with LTS times, but that's quite flaky IMO.

[GeoffreyBooth]

have this information built-in and trust in the environment to correctly check the date

Yes, that's how we would do it. The EOL dates are set years in advance. If someone's system has the wrong date set in their clock, so be it. It's just a warning. The warning itself can include the EOL date; see my example above.

[ljharb]

Despite being set years in advance, node 16’s EOL date was moved up (for example). Releasers may have conflicts that delay the date as well. If dates are hardcoded, there will inevitably be a time when they’re wrong (setting aside that system clocks are often incorrect and timezones are complex and often change according to government whim)

[mcollina]

I'm open to suggestions on how to encourage folks to upgrade.

[ljharb]

If security warnings from automated tooling, performance improvements, lack of platform support, and new features aren’t incentive enough for a user, what are the reasons node needs to be concerned with what version they’re using?

[meyfa]

It doesn't make sense to hardcode a timebomb into node, especially one that won't even necessarily be accurate.

This is not a timebomb - it's a warning message. I'm also not convinced that inaccuracy is a problem here. If EOL is moved one week back, users will be incentivized to upgrade one week earlier than they otherwise would be - nothing else happens. How is this a problem? Especially since they should really be upgrading before EOL anyway, since any security issue even one day after EOL would not be fixed.

[ljharb]

Spurious console output can definitely break things, like log parsing, child process output parsing, etc.

[mcollina]

Are you saying that it is ok that 50% of our users have not yet updated to a maintained version? This is an interesting take.

[BethGriggs]

I'm open to suggestions on how to encourage folks to upgrade.

I'd suspect we'd get more benefit from:

• More notification of timelines through regular communication channels (changelog, socials, etc.)
• Investing the effort in providing a comprehensive upgrade guide or mitigation path for all breaking changes
  • Even explore if tooling is possible to support this
• And generally reducing the number of breaking changes where possible

I really do suspect that this warning in most cases would either go unseen in abandoned/legacy projects or just irritate people who know they're stuck on old versions. Also, surely a lot of people stuck on old versions of Node.js are also stuck on old npm versions of modules that still support those versions? I can imagine many are already getting a number of npm audit warnings in their output.

(Not -1, but generally think our efforts are better placed elsewhere to encourage people to upgrade.)

[BethGriggs]

Are you saying that it is ok that 50% of our users have not yet updated to a maintained version? This is an interesting take.

I cannot see anywhere in this thread where anyone has that position. And, this issue was abruptly closed when I proposed genuine suggestions to encourage upgrades 😕

[mcollina]

I haven't seen your message when I closed this @BethGriggs. Reopening.

[ljharb]

To be clear, it’s not that it’s OK, it’s that i suspect it’s likely beyond the power of node to control, and that the warnings will likely cause more problems for users who want and know to upgrade, than it will help inform and motivate unaware users to do so.

[Trott]

Opt-in or opt-out?

I think it would be very valuable going forward if there was a way to tell people when they are running an out of date and unsupported version of Node.js. I do not know the best way to do that, but I do think we should have something available. Assuming that there is agreement that it would be good to have something rather than nothing, than the first thing to figure out is probably whether it should be opt-in or opt-out.

If it's opt-in with no plans to switch to opt-out with a future version, then there are several possibilities that otherwise aren't available. Some possibilities are:

• a CLI flag
• an environment variable
• an API call hung off a built-in module such as node:process or even node:test-runner, or even create a whole new internal module like node:checker or something like that which can do all sorts of health checks
• a separate script/tool we ship with Node.js

The downside is that most people probably won't run it. But it could be useful for CI and other situations.

If it's opt-in but where we want to keep the option of making it opt-out in the future, then that reduces the possibilities and still has the small-audience downside, but allows us to ship something as a proof-of-concept without it being something that will cause a lot of unexpected disruption.

Shipping something that is opt-out will notify the most people, of course, but risks the kind of warning-fatigue that we see with npm install warnings, where lots of people ignore long lists of "this module is insecure!" kind of warnings because there are so many of them and perhaps because a lot of them are inapplicable to their use case (such as a regex denial of service in a CLI tool dependency that doesn't ever get user-supplied data--yes, there are edge cases where this is still a problem, but you know the kind of thing I'm talking about so please refrain from being pedantic).

[ljharb]

I agree with that analysis - shipping an opt-in mechanism for a sizable period of time at least would provide a way to surface some of the potential issues mentioned.

[GeoffreyBooth]

Assuming that there is agreement that it would be good to have something rather than nothing

I think nothing is better than something that’s opt-in. We discussed that in #44942 and decided it wasn’t a good idea. Users already have plenty of ways to make a call to see if their current version of Node is the latest one, or in EOL. And anyone with the awareness to run an opt-in check doesn’t need us to notify them of anything.

Opt-out, however, I think is worth pursuing.

[Trott]

I think nothing is better than something that’s opt-in. We discussed that in #44942 and decided it wasn’t a good idea.

@GeoffreyBooth What makes you say there was a decision that it wasn't a good idea? That's not my impression, reviewing the conversation.

People involved in that conversation who seemed to conclude that opt-in was a viable option include:

1. @BridgeAR in Adding a Version Checker #44942 (comment)
2. @ljharb based on their thumbs-up reaction to @BridgeAR's comment
3. Me in Adding a Version Checker #44942 (comment) and Adding a Version Checker #44942 (comment)
4. @jasnell in Adding a Version Checker #44942 (comment)
5. @bnb in Adding a Version Checker #44942 (comment) and again in Adding a Version Checker #44942 (comment)
6. @ruyadorno based on their thumbs-up reaction to the first of @bnb's comment and the second of my comments

The only people I see in that conversation that seem opposed to opt-in seem to be:

1. @GeoffreyBooth in Adding a Version Checker #44942 (comment)
2. @ovflowd in Adding a Version Checker #44942 (comment)

I suppose you could also add the people who concluded that any type of version checker isn't going to be useful, but I don't see too many of those. (Maybe @RaisinTen?) Perhaps I'm not reading closely enough and doing too much searching-for-the-term-"opt-in", but I'm not seeing any widely-endorsed conclusion that it's not a good idea.

[GeoffreyBooth]

What makes you say there was a decision that it wasn't a good idea? That's not my impression, reviewing the conversation.

I was basing it on the fact that that issue was closed and nothing got implemented. Sure that's not a decision, I should more accurately have described it as an outcome.

[Trott]

• Investing the effort in providing a comprehensive upgrade guide or mitigation path for all breaking changes

A long time ago, @Fishrock123 used to put together those types of guides and then found it to be an impossible amount of work at some point. However, the challenge would be greatly reduced if coupled with another suggestion from @BethGriggs:

• And generally reducing the number of breaking changes where possible

[github-actions]

There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale Mark issue so that it is never considered stale label or close this issue if it should be closed. If not, the issue will be automatically 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.

[github-actions]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

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