Being able to bump engines

Clear and concise description of the problem

Suggested solution

add support for it

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Status check — partially unblocked, not done.

The packageRules engine (#1384) makes engines expressible as a rule target: matchDepTypes: ['engines'] resolves and routes correctly through resolveRuleEffects. What's missing is the other half — the npm scanner does not yet detect engines entries in package.json, so no update is ever produced for a rule to match.

Remaining work is contained: parse engines in parsePackageJsonFile, resolve latest runtime versions (Node from the release schedule, Bun from its releases API), and emit them as updates with dependencyType: 'engines'. The writer path already preserves formatting for package.json, so no new file-writing work is needed.

Half-unblocked as of 12d282f and 48e81ff: rules can target engines via matchDepTypes, and the adapter interface (src/ecosystems/types.ts) is the seam a detector would plug into. The scanner still does not surface engines as a dependency, which is the remaining work. Tracked as a leftover on #1385.

Landed in bc1a59f.

engines are extracted as dependencies with their own engines type, so rules can target them and they can be held back independently of ordinary updates.

bumpEngineConstraint preserves both the operator and the precision: someone who wrote >=20 gets >=22, not >=22.3.0. Rewriting a floor to an exact version turns 'runs on 20 or newer' into 'runs only on 20.11.1' and breaks every contributor on a different patch release. A range expression like >=18 <21 is a deliberate window and is left alone.

Known engines (node, bun, npm, pnpm, yarn, deno) are mapped explicitly to their release source — node and deno publish on GitHub, the rest on npm. An unknown engine is skipped rather than guessed at, since a wrong slug resolves versions for an unrelated package.

One bug found by the tests: the precision comparison went component-wise without stopping at the first difference, which called 22.3 a downgrade from 20.5. Now lexicographic.