npm: library author engines support

[rarkins]

Tell us more.

Although it's "easier said than done", I would like to help JS library authors to bump their Node.js engines values whenever there's changes in Node LTS.

I don't think there's a one size fits all, for example the majority may wish to support strictly "LTS only", others may support LTS+current, and others may extend support to older LTS releases such as Node 16 which are in maintenance mode. Others may wish to support non-LTS current releases too.

What matters is that at the right time, Renovate proposes a PR to all the applicable projects, modifying the engines field in package.json, and applying a "breaking change" semantic commit message if applicable.

If we try to make this purely automatic, it may be too challenging. I am open to this being done with presets which are manually modified.

One thing we may not be able to do is support everyone's custom/preferred semver syntax for this. Complex semver constraints can be hard to parse and understand.

I anticipate that to support this feature we may need:

• Hand-crafted and hand-maintained presets, and
• A new or modified concept for Renovate for how to apply such "changesets"

[rarkins]

On a related note: for those who apply "LTS only" or even "LTS + Current", would your constraint include ^20 or ^20.9.0 because that was the release where Node 20 went LTS? If you are "generous" and support ^20 then you have a compatibility problem if any of your upstream dependencies chose ^20.9.0 (even though probably everything works anyway)

Similarly, is it up to library authors to bump their minimum version of release streams in case of security releases, or leave that for downstream applications to determine? For example, Node 20.12.1 included a security fix earlier this month.

In other words three people saying they support Node LTS may have different interpretations of that:

• ^20.0.0 (all of v20)
• ^20.9.0 (all of v20 since it turned LTS)
• ^20.12.1 (v20 excluding known insecure versions)

[viceice]

I would prefer the last version, because sometimes you like to use features which are back ported to lts, so you need to ensure at least that higher lts version

[rarkins]

Isn't the last version (security fixes) fairly unrelated to backported features?

[viceice]

yes, you're right. it should only the minor.

[HonkingGoose]

Propose safest LTS version by default

In other words three people saying they support Node LTS may have different interpretations of that:

• ^20.0.0 (all of v20)
• ^20.9.0 (all of v20 since it turned LTS)
• ^20.12.1 (v20 excluding known insecure versions)

We should nudge users towards the safest option. The goal of updating is to get improvements, and security fixes. Therefore we should only propose safe versions of Node.js. So Renovate's default behavior should be:

• ^20.12.1 (v20 excluding known insecure versions)

If maintainers want to allow unsafe versions of Node.js, they must opt-in via a special Renovate config preset.

Stay away from complex/preferred SemVer syntax

One thing we may not be able to do is support everyone's custom/preferred semver syntax for this. Complex semver constraints can be hard to parse and understand.

We should keep things simple, at least for the first pass of this feature:

• Only latest LTS version
• Latest LTS + latest current version
• Only LTS versions
• Only current version

Again, all those versions should be the latest version, to minimize security risks.

If users want more complex behavior, they can create that configuration themselves.

[ljharb]

I am very concerned with automated encouragement of breaking changes - major bumps are the most costly and harmful thing for the JS ecosystem.

[rarkins]

ESM-only is quite a different topic. e.g. a change to ESM breaks close to 100% of existing users, dropping a very old Node.js version may not break any.

If "most people don't upgrade" or "most people are X" are bad practices then doesn't mean we need to drag the whole industry down.

When Node.js releases new or improved features, your strategy is to carefully avoid using any of them because of backwards compatibility?

When you have dependencies, and those don't support Node.js >= 0.4, what do you do then? Isn't it misleading to present a package's engines as supporting some range X if the dependencies it relies on less than X?

Another question: do you support or encourage use of Node.js 0.x versions in production? Or you think end users should stick with supported/secure releases and simply you don't want to bump a major? i.e. you keep engines static so as not to bump major versions and not because you think it's a good idea to use or support insecure Node.js releases

[ljharb]

My strategy, if I need those new features (which I rarely do) is to use them via a package that provides a fallback for older node versions.

I don't use dependencies that don't support the same node versions I do - I use npx ls-engines to verify this, as well as CI itself.

I certainly do not encourage use of unsupported node versions in production applications, but not all usage of node is in a production application. "Support" is simply not the same as "encourage use of".

[rarkins]

I think you're the compatibility hero which the world doesn't deserve, but this approach would be a large burden on the majority of people who do or might write open source. Any time you go to make use of a Node.js feature you have to check if it existed since 0.4.

Do you agree that someone starting out now with a new library should start with only LTS releases?

[ljharb]

I agree that when starting out with a new library, any choice is reasonable, including "only LTS".

Again, in practice - with my now 500 npm packages over the past decade - it is simply a non-burden, a non-issue, entirely, to do this check. The extra effort I've had to spend to retain compatibility is incredibly minimal.

[HonkingGoose]

Yes, to all of those questions. I'm 100% sure, because my CI runs in all those node versions.

First off, I'm really impressed how you're willing to test all versions of Node.js for that many packages.

My assumptions:

• You're testing all versions of Node.js for all 500 npm packages with CI
• You're willing to keep doing this for as long as you're able
• You're willing to deal with security issues for your packages due to supporting old Node.js versions

Even if all the above is doable and fun for you, I think it's not sustainable in another way: increased carbon emissions for all the extra testing.

The Node.js releases file says they released 24 versions of Node to date. I assume you're testing all those 24 versions in your CI for all your 500 packages, like this:

Packages	Number of Node.js version	Total versions to test
500	24	12000

Let's say in future you only support the latest LTS, and the latest current version of Node.js:

Packages	Number of Node.js versions	Total versions to test
500	2	1000

The difference is 12000 - 1000 = 11000 versions. To me it seems like a big spend of compute time, electricity, for a relatively minor gain of downstream users to keep using really old versions of Node.js

[badeball]

As a library developer and someone who's interested in this - here's my two cents.

I maintain an engines property similar to 16 || 18 || 20 || >= 22. If node releases a new version in the 16-line, I see no reason for why my library needs to be updated. Sure - one might say that users should be encouraged to upgrade to safer minor/patch versions, but for my library to impose that is nonsensical to me.

With the above-mentioned pattern, I am making the assumption that if something works in node x.0.0, it will for all x.y.z.. Whether that's safe or not is a different discussion.

Also I agree with @ljharb sentiment:

The extra effort I've had to spend to retain compatibility is incredibly minimal.

I don't always care - but when I do, the extra work to support more node versions has been minimal.