npm: Add support for node compatibility checks

[sidharthachatterjee]

What would you like Renovate to be able to do?
It would be very nice if Renovate supported some more compatibility checks (beyond semver versions) like the engine field in a package's manifest for instance. An example scenario follows:

Changing the engine key in package.json from 6 to >= 8 for example is a breaking change (for us) and we've seen some packages in the wild do it in patch updates. Currently Renovate would (rightly) open a PR including this update.

It would be nice if it was possible to skip this update by virtue of the engine key no longer being compatible.

Describe the solution you'd like
Check the engine key in a package's manifest and use that to test compatibility.

Describe alternatives you've considered
Hope and pray that packages in the wild respect semver? 🤷‍♂

Additional context
None

[rarkins]

Can you locate any packages that have done it? We need to study the npm metadata to see what we can work with.

[wardpeet]

Thanks @sidharthachatterjee. It's not just patch versions. It also helps us with major deps as we have to go through each package.json to see if we are compatible.

Having them not in the list of the renovate bot issue would be amazing or maybe somewhere at the bottom.

[sidharthachatterjee]

@wardpeet Remember any example case of a package doing this?

[rarkins]

Generally with compatibility we completely suppress incompatible versions. So this would mean that you wouldn't even see the updates/PRs until one day in the future where you update your engines or config somehow. Is that what you're after?

[sidharthachatterjee]

@rarkins Yup, while it would be nice to see them in the master issue, completely suppressing them should be fine too

[rarkins]

BTW even a major update should be fine to test against, just need some examples

[wardpeet]

On this issue gatsbyjs/gatsby#16840
You can find the following incompatible versions:

• fix: update dependency css-loader to v3
• fix: update dependency file-loader to v4
• fix: update dependency got to v9
• fix: update dependency style-loader to v1
• chore: update dependency stylelint to v12

There are probably some more but this should get you going ^^

Our engine is set to node 8.0.0

[rarkins]

On master branch package.json I see "node": ">=6.11.5". Isn’t that what we should be looking at?

[wardpeet]

Seems like we never changed the root package.json. For dependencies, it should check the engine where it is defined in. For devDependencies it should do the same unless it's in a monorepo than it should look at the root one.

This is the idea I had, unsure if it make sense so feel free to tweak it.

[rarkins]

Logic-wise I think we need to exclude any package that has a minimum version higher than your minimum? Even if by a patch? And if you have updated to an “incompatible” dependency already it would mean we ignore all upgrades for it or suggest to downgrade it? Lots of edge cases..

[wardpeet]

Logic-wise I think we need to exclude any package that has a minimum version higher than your minimum?

Yes 👍

And if you have updated to an “incompatible” dependency already it would mean we ignore all upgrades for it or suggest to downgrade it? Lots of edge cases..

I don't think it's necessary to downgrade to get this shipped. It might be a nice follow-up.

[ljharb]

The way I think this should work is that if a project has declared "engines.node", and it's not set to "*", and the dependency being added declares an "engines.node" range that is not a superset of the project's range (ie, if the project is ">= 8" and the dep is ">= 10"), that it should be (configurably) skipped, or notified, but not suggested as an upgrade via a PR.

https://npmjs.com/ls-engines may help with this - iow, the ideal output before the dep should be the same output after the dep.

[rarkins]

I like the idea of simply checking that the candidate version's node constraint produces a subset of the repo's node constraint, and skip the candidate version if so. We could try calculating that "algebraically" but it's perhaps simpler and more foolproof to simply fetch the list of known node versions once and then filter and compare.

[rarkins]

Next step: a simple "reproduction" repo that today generates PRs for incompatible node versions.

[ljharb]

Combining the list of node versions from https://nodejs.org/dist/index.tab with the semver package should you calculate it relatively trivially.

[ljharb]

Sounds great to me.

I'm pretty sure npm's own algorithm is usable in https://npmjs.com/@npmcli/arborist, but you'd have to dig to figure out exactly which.

[github-actions]

Hi there,

Help us by making a minimal reproduction repository.

Before we can start work on your issue we first need to know exactly what's causing the current behavior. A minimal reproduction helps us with this.

To get started, please read our guide on creating a minimal reproduction to understand what is needed.

We may close the issue if you (or someone else) have not provided a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.

Good luck,

The Renovate team

[rarkins]

Can anyone put together a reproduction repo? An example could be:

• Current repo's engines say Node 16 or 18
• Latest version of a dependency supports Node 18 only

[remal]

@rarkins, take a look: remal-github-actions/template-typescript#687

@octokit/plugin-throttling v6 supports Node >= 18. However, my .nvmrc says that Node v16 should be used.

I don't want @octokit/plugin-throttling to be updated to v6 until I upgrade Node.js.

Renovate does see that Node.js constraint is v16:

DEBUG: Using node constraint "16" from .nvmrc

[rarkins]

@remal this feature would need to be based on the engines constraints and not .nvmrc if it is to be accurate. In your case you have >= 16 in engines: https://github.com/remal-github-actions/template-typescript/blob/248061d6e62fc960d0c5afd57f178bb62cad688e/package.json#L5-L7

I prototyped the feature using https://github.com/renovate-reproductions/4826 but already we see in this feature that it gets complicated. A number of dependencies you are using do support Node 16 but only the LTS range, e.g. ^16.10.0. This means that technically they do not support your engines constraints and need to be rolled back if strict mode was on. Example, ts-jest supports "^14.15.0 || ^16.10.0 || >=18.0.0"

Even with that resolved, the next problem is that your declaration of >= 16 means that v17 is supported too. A library like ts-jest doesn't support v17, so therefore isn't compatible.

I reduced the noise by doing strict filtering only for dependencies (i.e. not devDependencies) and all rollback PRs were closed: https://github.com/renovate-reproductions/4826/pulls?q=is%3Apr+sort%3Aupdated-desc+is%3Aclosed

But I still think this feature needs further brainstorming before it's ready.

[remal]

I looked at Removate sources today and found that it looks at .nvmrc first, then some other file (don't remember), and only then - package.json.

I left >=16 in package.json, because I don't want to limit the local environment. However, my CI/CD jobs are strictly limited to Node.js v16 (GitHub actions don't support Node 18 runtime at the moment).

What I'd like Renovate to do is not to update dependencies to versions that require Node v17, 18, etc. Is it possible? If yes, the how? Do you have any other suggestions for my case?

[rarkins]

I looked at Removate sources today and found that it looks at .nvmrc first, then some other file (don't remember), and only then - package.json.

You're mixing up two related concepts:

• What you're seeing there is "how should Renovate decide which version of Node.js to install before running npm install to update lockfiles?"
• What we're talking about here is "how should Renovate decide if dependency versions are compatible with your library?"

In the first case Renovate needs to pick one version - so using .nvmrc makes most sense. In the second case it needs to make sure that the package supports all versions you need - not just one.

I left >=16 in package.json, because I don't want to limit the local environment. However, my CI/CD jobs are strictly limited to Node.js v16 (GitHub actions don't support Node 18 runtime at the moment).

This is up to you, but it will influence the lookup logic

What I'd like Renovate to do is not to update dependencies to versions that require Node v17, 18, etc. Is it possible? If yes, the how? Do you have any other suggestions for my case?

First of all, this is not possible today and that's why this issue is open.

But once it's implemented, then either you declare your engines as narrower, such as ^16.10.0, or you would manually configure config.constraints to override your declared engines.

[rarkins]

PR now open: #22447

[remal]

@rarkins, as I can see, the PR is merged. But I still couldn't make it work for this repo: https://github.com/remal-github-actions/template-typescript. Should it work? Is it still in progress? Am I doing something wrong?

[rarkins]

It's part of the v36 branch so not part of an official release yet

[renovate-release]

🎉 This issue has been resolved in version 36.0.0 🎉

The release is available on:

• GitHub release
• 36.0.0

Your semantic-release bot 📦🚀