Prefer `node-version-file: package.json` over $PATH by default

[fregante]

Description:

- uses: actions/setup-node@v5

Currently 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.json

The 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

[marko-zivic-93]

Hello @fregante Thank you for creating this issue. We will investigate and come back to you as soon as we have some feedback.

[aparnajyothi-y]

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]

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

[aparnajyothi-y]

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]

without node-version-file, on @main ❌

Still no luck

• package.json: https://github.com/fregante/webext-storage/blob/347dccdb09eb2d3b4a71e23b1c6b2ac2ccd22272/package.json#L60-L62
• workflow: https://github.com/fregante/webext-storage/blob/347dccdb09eb2d3b4a71e23b1c6b2ac2ccd22272/.github/workflows/ci.yml#L12
• run using the default v18 instead of the engines field: https://github.com/fregante/webext-storage/actions/runs/7570275738/job/20615307302

[fregante]

we have merged the code as part of this PR

That PR is unrelated to this feature request.

The tests on main specifically verify the opposite of this feature request, right?

https://github.com/actions/setup-node/blob/d86ebcd40b3cb50b156bfa44dd277faf38282d12/tests/main.test.ts#L185-L187

[hilja]

Great issue and great research. I was just wondering the same thing, would be great if the version would just work™

[kleinfreund]

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 run npm install --global npm@... after actions/setup-node which is cumbersome.

[fregante]

@kleinfreund that's unrelated, this request is exclusively about changing a default. For what you're asking refer to:

• https://github.com/actions/setup-node/issues/529

[mk-pmb]

I added this one to my suggested way of merging all the version number oracles over here in issue 939.

I wish I didn't have to clutter all of my jobs with

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.

[aparnajyothi-y]

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]

@aparnajyothi-y i'm not sure to follow why i'm mentioned in @fregante 's issue 🤔

[fregante]

breaking change for a large number of workflows

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?