You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description: devEngines field is now supported by npm and corepack.
If user set node-version-file: package.json in yaml, setup-node action should consult both engines and devEngines fields, while currently only engines works.
Justification:
In monorepo, the root package.json usually have no engines field. Moreover, the engines is for users who install the npm package, while the devEngines field is for who developers who develop the npm package. Obviously, devEngines is more suitable for setup-node.
And if anyone is working on this, maybe you could also consider factoring in the volta node field?
Then you could run volta pin node@23.11.0 which would fetch and install node, set the node version in package.json volta.node and that's all you have to do
@mklueh volta is not the standard, but devEngines is the standard which is supported by npm, pnpm, corepack ...
BTW I don't consider volta until it stablely supports pnpm.
Hello Everyone, Thanks for the detailed feedback and examples shared here. Based on the discussion and internal review, we agree this would be a useful enhancement with minimal impact on existing workflows.
We’re planning to extend node-version-file: package.json to also consider devEngines, with the following precedence:
volta.node → devEngines.runtime → engines.node
This keeps the current behavior unchanged unless devEngines (or volta) is explicitly defined, while better supporting developer-focused and monorepo setups. We’ll ensure the precedence is clearly documented and will share updates as the implementation progresses.
Please feel free to reach if you have any questions or concerns regarding this change.
Reacted by Kutsan Kaplan and Takuya Fukuju
Reacted by Eli, Kutsan Kaplan, Peter Abrahamsen, Callum Watkins and Nozomi Ishii
Activity
suyashgaonkar commentedon Mar 24, 2025
Hi @zanminkian , Thank you for creating this feature request. We will investigate it and provide feedback as soon as we have some updates.
mklueh commentedon Apr 13, 2025
And if anyone is working on this, maybe you could also consider factoring in the volta node field?
Then you could run
volta pin node@23.11.0which would fetch and install node, set the node version in package.jsonvolta.nodeand that's all you have to dohttps://docs.volta.sh/reference/pin
But maybe it would be better to let volta handle the devEngines update instead of making this action volta-aware
susnux commentedon Apr 20, 2025
@mklueh but the volta field is already supported? #921
zanminkian commentedon Jul 30, 2025
@mklueh volta is not the standard, but
devEnginesis the standard which is supported by npm, pnpm, corepack ...BTW I don't consider
voltauntil it stablely supports pnpm.chore: specify dev engines field in package.json (#321)
chore: specify dev engines field in package.json (#321)
zanminkian commentedon Dec 19, 2025
Here is a workaround to support devEngines:
v-aparnajyothi-y commentedon Jan 28, 2026
Hello Everyone, Thanks for the detailed feedback and examples shared here. Based on the discussion and internal review, we agree this would be a useful enhancement with minimal impact on existing workflows.
We’re planning to extend node-version-file: package.json to also consider devEngines, with the following precedence:
volta.node → devEngines.runtime → engines.node
This keeps the current behavior unchanged unless devEngines (or volta) is explicitly defined, while better supporting developer-focused and monorepo setups. We’ll ensure the precedence is clearly documented and will share updates as the implementation progresses.
Please feel free to reach if you have any questions or concerns regarding this change.