fix(action): set LOCKFILE when package-manager is explicitly specified (#98)

[pekkanikander]

Fixes #98.

Note well

I have prepared this PR with the help of Claude Code and ChatGPT Codex, using them to cross-check each other's work. I have personally reviewed the code thoroughly, as well as this PR, but as I don't personally know some of the package managers involved, there may be subtle bugs that have gone unnoticed.

What was wrong

When package-manager is explicitly set by the user, the "Check lockfiles" step in action.yml sets PACKAGE_MANAGER but never LOCKFILE. All auto-detection branches set both; the explicit branch sets only the former.

With LOCKFILE unset, cache-dependency-path gets evaluated to "./", which gets expanded in actions/setup-node recursively to every file in the workspace; see #98.

Changes

action.yml

1. "Check lockfiles" step:

After PACKAGE_MANAGER is set in the explicit branch, a case statement maps it to the expected lockfile name. LOCKFILE is written to $GITHUB_ENV only if the named file exists on disk. If the file does not exist, e.g. because the lockfile is gitignored, a warning annotation is emitted and LOCKFILE is left unset.

2. Setup Node steps:

The single "Setup Node" step is split into two mutually exclusive steps conditioned on env.LOCKFILE:

• with lockfile cache (env.LOCKFILE != ''): behaviour unchanged from before — passes cache and cache-dependency-path as before.

• without lockfile cache (env.LOCKFILE == ''): sets cache: to empty and package-manager-cache: false to fully disable node_modules caching and avoid a hard failure from actions/setup-node.