npm: library author engines support #28384
Replies: 2 comments 13 replies
-
|
On a related note: for those who apply "LTS only" or even "LTS + Current", would your constraint include 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:
|
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Isn't the last version (security fixes) fairly unrelated to backported features? |
Beta Was this translation helpful? Give feedback.
-
|
yes, you're right. it should only the minor. |
Beta Was this translation helpful? Give feedback.
-
Propose safest LTS version by default
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:
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
We should keep things simple, at least for the first pass of this feature:
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. |
Beta Was this translation helpful? Give feedback.
-
|
I am very concerned with automated encouragement of breaking changes - major bumps are the most costly and harmful thing for the JS ecosystem. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 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". |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
First off, I'm really impressed how you're willing to test all versions of Node.js for that many packages. My assumptions:
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:
Let's say in future you only support the latest LTS, and the latest current version of Node.js:
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 |
Beta Was this translation helpful? Give feedback.
-
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
enginesfield inpackage.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:
Beta Was this translation helpful? Give feedback.
All reactions