Repository navigation
Prefer node-version-file: package.json over $PATH by default #912
Description
Description:
- uses: actions/setup-node@v5Currently this uses what's available in $PATH, but I reckon it should prefer what the user already specified as a compatible node version in the package.json.
Justification:
It feels strange that a project clearly and "natively" specifies what version it's expected to run on, but the environment ignores it, requiring further config.
I love that node-version-file: package.json is possible now, but I wish I didn't have to clutter all of my jobs with
- uses: actions/setup-node@v4
with:
node-version-file: package.json
. . .
- uses: actions/setup-node@v4
with:
node-version-file: package.json
. . .
- uses: actions/setup-node@v4
with:
node-version-file: package.jsonThe drawback is that in the rare situation where the user wants to use what's in PATH, as opposed to what's in package.json, now they'd need something like node-version: PATH. But again this feels like it should be the minority.
Are you willing to submit a PR?
Potentially
Activity
marko-zivic-93 commentedon Dec 11, 2023
Hello @fregante
Thank you for creating this issue. We will investigate and come back to you as soon as we have some feedback.
v-aparnajyothi-y commentedon Jan 9, 2024
Hello @fregante, We've merged the fix for the issue as part of another issue. Could you please try to use actions/setup-node@main to confirm that it works as expected?
fregante commentedon Jan 9, 2024
Thank you! Unfortunately that didn't seem to work.
https://github.com/fregante/webext-storage/blob/1c8d4174ef90406b56499f6ecdef49b6e0f6a1e2/.github/workflows/ci.yml
with node-version-file ✅
https://github.com/fregante/webext-storage/actions/runs/7458660958
without ❌
https://github.com/fregante/webext-storage/actions/runs/7458664070
v-aparnajyothi-y commentedon Jan 18, 2024
Hello @fregante, Thank you for testing.
Could you please replace the setup-action repository actions/setup-node@v4 in your workflow with actions/setup-node@main because we have merged the code as part of this PR and yet to release.
Please replace the branch with main and update the results. Hope that should fulfil your requirement.
fregante commentedon Jan 18, 2024
without node-version-file, on
@main❌Still no luck
enginesfield: https://github.com/fregante/webext-storage/actions/runs/7570275738/job/20615307302fregante commentedon Jan 18, 2024
That PR is unrelated to this feature request.
The tests on
mainspecifically verify the opposite of this feature request, right?setup-node/__tests__/main.test.ts
Lines 185 to 187 in d86ebcd
hilja commentedon Jan 19, 2024
Great issue and great research. I was just wondering the same thing, would be great if the version would just work™
kleinfreund commentedon Apr 23, 2024
Additionally, this would provide a nice way to configure both the node and npm version. Currently, actions/setup-node will install a npm version that does generally not match
pkg.engines.npm. If one wants to ensure that the npm version is the same as the one used locally, one has to runnpm install --global npm@...afteractions/setup-nodewhich is cumbersome.fregante commentedon Apr 23, 2024
@kleinfreund that's unrelated, this request is exclusively about changing a default. For what you're asking refer to:
mk-pmb commentedon Jun 12, 2024
I added this one to my suggested way of merging all the version number oracles over here in issue 939.
The many repetitions of the same "with:" parameters are not specifically related to this one option. It should thus be an issue of its own, and should probably be solved by a config file mechanism.
The current best stopgap seems to be to make a separate workflow job for installing node, and have your other jobs depend on that.
v-aparnajyothi-y commentedon Oct 30, 2025
Hi @y-nk, thank you for this feature request. After internal evaluation and considering existing usage patterns, we've decided to keep the current precedence behavior (node-version > node-version-file). Reversing this logic would be a breaking change for a large number of workflows, and at this time we’re not planning to introduce it as a feature.
We do recognize the value of the fallback behavior you proposed, especially for monorepo setups. We're closing this issue for now and we'll keep this suggestion in mind for future iterations if we explore safer ways to improve version resolution without impacting backward compatibility.
Please feel free to reach us in case of any further concerns or clarification to reopen this issue:)
y-nk commentedon Oct 30, 2025
@aparnajyothi-y i'm not sure to follow why i'm mentioned in @fregante 's issue 🤔
fregante commentedon Oct 30, 2025
Isn't that what semver is for? No CI is going to serendipitously break because the current version remains unchanged.
What's the point of breaking versions if no breaking changes are allowed?