GitHub Actions · actions/setup-node · Checked November 3, 2026

GitHub Actions: "Dependencies lock file is not found"

actions/setup-node was set to cache the package manager's downloads, and the cache key is a hash of the lock file. It found no lock file to hash, so the step failed before anything was installed. It looks in one place only: the top of the workspace (GITHUB_WORKSPACE).

What it looks like

Error: Dependencies lock file is not found in /home/runner/work/app/app. Supported file patterns: package-lock.json,npm-shrinkwrap.json,yarn.lock

• The patterns follow the cache input: npm accepts package-lock.json, npm-shrinkwrap.json or yarn.lock, yarn only yarn.lock, pnpm only pnpm-lock.yaml.
• If the line before it says "Detected npm as the package manager from package.json's packageManager field", there is no cache input at all (3).
• With cache-dependency-path, the same problem reads "Some specified paths were not resolved, unable to cache dependencies." (5).

1. The lock file is in a subfolder

The action lists the files at the top of the workspace and nothing below it. It does not follow defaults.run.working-directory, which applies to run steps only. Point it at the file:

- uses: actions/setup-node@v7
  with:
    node-version: 24
    cache: npm
    cache-dependency-path: frontend/package-lock.json

For several projects, list one path per line (cache-dependency-path: |), as the action's advanced usage guide shows. If the root package.json declares npm workspaces, npm keeps a single lock file at the root, and npm ci there needs it too: pulsartrack added such a root package.json with lock files only in frontend/ and backend/, and three jobs failed at setup-node (pulsartrack #1086).

2. The lock file is not in the repository

• Removed: in site-lf-solucoes a pull request removed the lock file while the Lighthouse workflow kept cache: npm; Setup Node failed and no report was made (site-lf-solucoes #19).
• Never there: a fork's Docusaurus deploy ran setup-node with cache: npm on a tree with no package.json or lock file (home-assistant-frank_energie #9).
• Ignored by git: in h-dashboard, .gitignore lists package-lock.json while the file is tracked, so a cleanup that untracks it would break three jobs (h-dashboard #1293). git check-ignore -v package-lock.json shows which rule.

Commit the lock file, or remove cache when there is nothing to install.

3. A packageManager field turned caching on

Since v5.0.0 (September 2025), caching starts without any cache input when the root package.json has "packageManager": "npm@…" or a devEngines.packageManager named npm; v6.0.0 limited this to npm. A repository that sets the field but has no lock file fails on the upgrade. Commit the lock file, or turn it off:

- uses: actions/setup-node@v7
  with:
    node-version: 24
    package-manager-cache: false

The README recommends package-manager-cache: false anyway for workflows with elevated privileges or access to sensitive information.

4. A composite action set up its own Node

Inside a composite action, setup-node still searches the workspace of the repository that runs the workflow, not the action's folder. In a11ign, the action's own setup-node step with cache: npm failed in every caller repository that was not an npm project (a11ign #568). Pointing cache-dependency-path at the action's lock file under /home/runner/work/_actions/… does not help: the path is matched only inside the workspace, and the step fails with "Some specified paths were not resolved" (agentic-development-workflow #724). For an action's own dependencies, leave cache out and set package-manager-cache: false.

5. "Some specified paths were not resolved"

With cache-dependency-path, the action hashes the files that path matches from the workspace, and fails with this message when it matches none. In sapphire-sh's shared workflow the path was <working_directory>/package-lock.json, and callers passed an npm workspace member, whose folder has no lock file (github-actions #88). Use the path where the file is; the advanced usage guide also shows '**/package-lock.json' for lock files at any depth.

6. The files were not checked out

• A setup-node step before actions/checkout sees an empty workspace. Check out first.
• On a self-hosted runner that keeps its work directory, a job that checked out only package.json (sparse checkout) left the next job without the lock file, although that job's checkout reported no error (SOFTURE AI #687). GitHub-hosted runners start each job in a fresh directory.

Telling it apart

• "npm cache is not found" (or yarn, pnpm) in the setup-node log is not an error: there was no saved cache for this lock file yet, and the step goes on.
• "Caching for 'bun' is not supported": the cache input takes npm, yarn or pnpm only.
• "Unable to locate executable file: pnpm": with cache: pnpm, pnpm must be installed before setup-node; the advanced usage guide runs pnpm/action-setup first.
• Caches made with actions/cache report misses differently: "Cache not found for input keys".

See failed jobs from IntelliJ IDEA

Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).

GitHub and GitHub Actions are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with, sponsored or endorsed by GitHub, Inc. or JetBrains.

More: "Cache not found for input keys" · "Failed to save: Unable to reserve cache with key" · The "Node.js 20 is deprecated" warning · GitHub Actions plugins for IntelliJ IDEA compared · 日本語