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?

setup-node/__tests__/main.test.ts

Lines 185 to 187 in d86ebcd

	it('does not read node-version-file if node-version-file is not provided', async () => {
	// Arrange
	delete inputs['node-version-file'];

[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:

• Set npm/yarn/pnpm version  #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.