Issues with `env.LOCKFILE` when `package-manager` input is explicitly specified but there is no package manager cache

[pekkanikander]

When package-manager is explicitly set (e.g. package-manager: yarn), the "Check lockfiles" step in action.yml sets PACKAGE_MANAGER but never sets LOCKFILE. The auto-detection branches all set both; the explicit branch sets only one.

This causes cache-dependency-path in the "Setup Node" step to evaluate to "./" (a bare directory), which actions/setup-node
glob expands recursively to every file in the workspace, spawning a potentially large number of concurrent NodeJS processes, which in turn corrupts V8's startup snapshot cache and produces fatal crashes. See actions/setup-node#887

Steps to reproduce

1. Use a repo where the lockfile is not committed (e.g.yarn.lock is in .gitignore)
2. Set package-manager: yarn explicitly in the workflow
3. Run the action — the Setup Node step crashes

Expected behaviour

The cache-dependency-path should resolve to the lockfile path (e.g. ./yarn.lock),
identical to the existing auto-detection path.

If the lockfile is absent, caching should be skipped gracefully with a warning, rather than crashing.

Note well

This issue has been prepared with the help of Claude Code and ChatGPT Codex. I'm working on a fix with them and hope to land a PR soon, after some more testing.

[delucis]

Thanks for reporting @pekkanikander!

I don’t think we considered repos without a lock file. I guess we can fix in this line?

action/action.yml

Line 118 in 1e076ba

cache-dependency-path: "${{ inputs.path }}/${{ env.LOCKFILE }}"

If LOCKFILE is not set, we can just use the default "" empty string for this option to avoid this?

[pekkanikander]

Well, I never tested with just setting cache-dependency-path to an empty string instead of "./". That might be a simpler fix than PR#99, which does fix this at least for Yarn. PR#99 may be a bit heavy, but it does appear to fix this issue.

[delucis]

According to the setup-node docs, an empty string is the default value for that option so I guessed it might be ok to use that in this case.

My one concern with #99 is that it's a bit strange to point to a lock file if that file doesn't exist. I probably need to read through it more carefully to understand the details though.