Files
renovate/docs/usage/node.md
y.takahashi ff0e5eed24 feat(npm): support devEngines.runtime and devEngines.packageManager (#43369)
* feat(npm): extract devEngines.runtime and devEngines.packageManager

Adds extraction for the npm devEngines field
(https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines)
covering both single-object and array forms. Uses dot-notated depTypes
("devEngines.runtime", "devEngines.packageManager") consistent with
"pnpm.overrides", and reuses the existing engines/packageManager
datasource resolution. Items without a version are skipped.

Refs #38067.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* feat(npm): update devEngines.runtime and devEngines.packageManager versions

Adds an update path for the new devEngines depTypes. Handles both the
single-object form and the array form (the array element is identified
via managerData.devEnginesIndex set at extraction time). Uses the same
anchored search-and-verify approach as the existing replaceAsString
(indexOf("devEngines") + dequal check), so unrelated occurrences of the
same version string elsewhere in the file are not touched.

Refs #38067.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(npm): skip lockedVersion and apply @yarnpkg/cli for devEngines deps

Extends the locked-versions post-extract step to cover the new
devEngines depTypes:

- devEngines.runtime and devEngines.packageManager are added to the
  npm-lock skip list (mirrors the engines/packageManager/volta handling
  added in #38598)
- devEngines.packageManager with depName "yarn" gets the @yarnpkg/cli
  packageName fallback when the project is on Yarn 2+, matching the
  existing behavior for engines / packageManager

Refs #38067.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(npm): harden devEngines handling against malformed input

- Register devEngines.runtime and devEngines.packageManager in
  knownDepTypes (matches the existing pnpm.overrides pattern)
- Guard against null/non-object array elements in devEngines.* during
  extraction so malformed JSON does not throw
- Use JSON.stringify when interpolating versions into the source search
  string, so any future versions containing JSON-escaped characters are
  matched correctly
- Add an extraction test for a mixed array containing a null item, a
  valid entry, and a version-less entry

Refs #38067.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(npm): set hasPackageManager when devEngines.packageManager is an array

The previous hasPackageManager check used isNonEmptyObject which returns
false for arrays. Now that the array form of devEngines.packageManager
is actually extractable and updatable, the corepack post-update step
needs to be triggered for those users as well. Introduces a shared
hasDevEnginesPackageManager helper and uses it from both
extractPackageJson and extractPackageFile.

Refs #38067.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(npm): require at least one non-empty array item for hasPackageManager

Align the array branch of hasDevEnginesPackageManager with the
single-object branch by requiring at least one non-empty object item.
Previously, an array containing only null/empty entries would set
hasPackageManager to true and trigger corepack post-update even though
no usable item exists. Add coverage for the empty-array and
only-invalid-items cases.

Refs #38067.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* test(npm): document hasPackageManager semantics for stray-key array items

Make the chosen semantic explicit: an array element with arbitrary keys
but no `name` (e.g. `[{ foo: 'bar' }]`) still sets hasPackageManager to
true, mirroring the pre-existing single-object behavior. The extract
step independently filters out items lacking `name`/`version`.

Refs #38067.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* test(npm): cover dequal rejection in devEngines array update

Adds a test where two devEngines.packageManager array items share the
same version string. The first source-level match belongs to the wrong
index, so the dequal verification rejects it and the loop continues to
the correct occurrence. This exercises the false branch of the dequal
check in updateDevEnginesDependency.

Refs #38067.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(node): list devEngines.runtime as a supported field for Node.js

The npm manager now updates the version inside devEngines.runtime in
package.json, so include it in the file-support list alongside engines
and volta.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Apply the comment changes suggested in the code review

Co-authored-by: Michael Kriese <michael.kriese@gmx.de>

* test(npm): cover devEngines update error path instead of ignoring it

Remove the v8 ignore on the updateDevEnginesDependency catch and add a
test that reaches it with invalid JSON, matching how the main
updateDependency catch is covered.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(npm): drop unnecessary spread fallback in devEngines managerData

Object spread ignores null/undefined, so the `?? {}` fallback is
redundant. Removing it satisfies the oxlint no-unnecessary-spread-fallback
rule that now runs in CI.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* refactor(npm): type devEnginesIndex on NpmManagerData

Declare devEnginesIndex on NpmManagerData so the value no longer needs a
`as number | undefined` cast when reading it back during update.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs(node): document package manager version fields

List packageManager and devEngines.packageManager separately from the Node.js runtime file support entries.

Co-authored-by: Codex <noreply@openai.com>

* feat(npm): support Bun and Deno devEngines runtimes

* fix(npm): preserve Corepack hashes in devEngines

* test(npm): use partial helper for devEngines fixture

Co-authored-by: Codex <noreply@openai.com>

* fix(npm): warn on invalid devEngines update state

Co-authored-by: Codex <noreply@openai.com>

* fix(npm): include devEngines in extracted tool constraints

Co-authored-by: Codex <noreply@openai.com>

* fix(npm): prefer devEngines over volta for package manager versions

Co-authored-by: Codex <noreply@openai.com>

* fix(npm): update Yarn binaries for devEngines package manager upgrades

Co-authored-by: Codex <noreply@openai.com>

* fix(npm): recognize devEngines package managers for Yarn catalogs

Co-authored-by: Codex <noreply@openai.com>

* fix(npm): exclude devEngines from Yarn locked versions

Co-authored-by: Codex <noreply@openai.com>

* refactor(npm): reuse Bun extraction for devEngines runtime

Co-authored-by: Codex <noreply@openai.com>

* test(npm): cover Yarn devEngines manifest preservation and grouped updates

Co-authored-by: Codex <noreply@openai.com>

* refactor(npm): pass packageJsonResult directly to hasDevEnginesPackageManager

Co-authored-by: Michael Kriese <michael.kriese@gmx.de>

* test(npm): simplify malformed devEngines fixture

Co-authored-by: Codex <noreply@openai.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Codex <noreply@openai.com>
2026-10-01 11:25:52 +00:00

55 lines
3.0 KiB
Markdown

---
title: Node.js Versions
description: Node.js versions support in Renovate
---
# Node.js Versions
Renovate can upgrade the [Node.js](https://nodejs.org/en/) runtime used by your project.
This way you're using the latest bug fixes, performance improvements, security mitigations, etc.
## LTS codenames
Renovate understands [codenames for Node.js LTS releases](https://github.com/nodejs/Release/blob/main/CODENAMES.md) and will offer upgrades for them (e.g. from `fermium` to `gallium`) as long as the `node` versioning scheme is being used.
## File Support
Renovate can manage the Node.js version in the following files:
- The [`engines`](https://docs.npmjs.com/files/package.json#engines) field in [`package.json`](https://docs.npmjs.com/files/package.json)
- The [`devEngines.runtime`](https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines) field in [`package.json`](https://docs.npmjs.com/files/package.json)
- The [`volta`](https://docs.volta.sh/guide/understanding#managing-your-project) field in [`package.json`](https://docs.npmjs.com/files/package.json)
- The [`.nvmrc`](https://github.com/creationix/nvm#nvmrc) file for the [Node Version Manager](https://github.com/creationix/nvm)
- The [`.node-version`](https://github.com/nodenv/nodenv#choosing-the-node-version) file for the [nodenv](https://github.com/nodenv/nodenv) environment manager
- The [`.tool-versions`](https://asdf-vm.com/manage/configuration.html#tool-versions) file for the [asdf](https://github.com/asdf-vm/asdf) version manager
- The mise [configuration files](https://mise.jdx.dev/configuration.html#mise-toml) (e.g., `mise.toml`, `.mise.toml`, `.config/mise.toml`) for the [mise](https://github.com/jdx/mise) version manager
- The [`node_js`](https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#Specifying-Node.js-versions) field in [`.travis.yml`](https://docs.travis-ci.com/user/customizing-the-build/)
## Package manager versions
Renovate can manage the package manager version in the following fields in [`package.json`](https://docs.npmjs.com/files/package.json):
- The [`packageManager`](https://nodejs.org/api/packages.html#packagemanager) field
- The [`devEngines.packageManager`](https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines) field
## Configuring which version of npm Renovate uses
When `binarySource=install`, such as in the Mend Renovate App, Renovate will choose and install an `npm` version dynamically.
To control which version or constraint is installed, you should use the `engines.npm` property in your `package.json` file.
Renovate will then use that version constraint for npm when it creates a pull request.
For example, if you want to use at least npm `8.1.0` and also allow newer versions of npm in the `8.x` range, you would put this in your `package.json` file:
<!-- schema-validation-disable-next-block -->
```json title="package.json"
{
"engines": {
"npm": "^8.1.0"
}
}
```
Alternatively, the npm version can also be configured via the [`constraints` option](./configuration-options.md#constraints).