pnpm/pnpm · error · PnpmError

NO_PACKAGE_IN_DEPENDENCIES

NO_PACKAGE_IN_DEPENDENCIES

Error message

None of the specified packages were found in the dependencies of any of the projects.

What it means

Recursive (workspace-wide) update pre-flight: after building mutatedImporters from the selected projects, none of the selected projects would receive an update mutation. For `update` at the default depth 0 this means the requested specs matched no project's direct dependencies anywhere, so the command aborts before running anything rather than reporting a silent no-op.

Source

Thrown at pnpm11/installing/commands/src/recursive.ts:340

            modulesDir,
            mutation,
            pruneDirectDependencies: opts.pruneDirectDependencies,
            rootDir,
            update: opts.update,
            updateMatching: opts.updateMatching,
            updatePackageManifest: opts.updatePackageManifest,
            updateToLatest: opts.latest,
          } as MutatedProject)
      }
    }))
    if (!opts.selectedProjectsGraph[opts.workspaceDir as ProjectRootDir] && manifestsByPath[opts.workspaceDir as ProjectRootDir] != null) {
      mutatedImporters.push({
        mutation: 'install',
        rootDir: opts.workspaceDir as ProjectRootDir,
      })
    }
    if ((mutatedImporters.length === 0) && cmdFullName === 'update' && opts.depth === 0) {
      throw new PnpmError('NO_PACKAGE_IN_DEPENDENCIES',
        'None of the specified packages were found in the dependencies of any of the projects.')
    }
    const {
      updatedCatalogs,
      updatedProjects: mutatedPkgs,
      ignoredBuilds,
      newLockfile,
      resolutionPolicyViolations,
      dryRunResult,
    } = await mutateModules(mutatedImporters, {
      ...installOpts,
      storeController: store.ctrl,
      resolutionVerifiers: store.resolutionVerifiers,
    })
    if (opts.save !== false && !opts.dryRun) {
      // Only pick entries when we'll actually persist. Otherwise the
      // info log would claim entries were added that the workspace
      // manifest never saw, and the next install would re-prompt or

View on GitHub (pinned to 5b11d3a15b)

Solutions

Find which workspace projects actually depend on it: `pnpm why <pkg>` or `pnpm -r ls <pkg>`, and fix the spec spelling.
Widen or fix the --filter selection so projects that have the dependency are included.
If the dependency is only transitive, run with `--depth <N>` (depth 0 is what turns the no-match into an error).
If you intended an install rather than an update of a new package, use `pnpm -r add <pkg>`.

Example fix

# before
pnpm -r update lodash-es   # ERR_PNPM_NO_PACKAGE_IN_DEPENDENCIES (no project has it)
# after — find the owner, then target it
pnpm why lodash-es
pnpm --filter my-app update lodash-es

Defensive patterns

Strategy: validation

Validate before calling

import { readFile } from 'node:fs/promises'

async function anyProjectDependsOn (projectDirs: string[], name: string): Promise<boolean> {
  for (const dir of projectDirs) {
    const manifest = JSON.parse(await readFile(`${dir}/package.json`, 'utf8'))
    const has = ['dependencies', 'devDependencies', 'optionalDependencies']
      .some(field => manifest[field] != null && name in manifest[field])
    if (has) return true
  }
  return false
}

if (!(await anyProjectDependsOn(selectedDirs, specName))) {
  throw new Error(`no selected project depends on ${specName}`)
}

Type guard

import util from 'node:util'

function isRecursiveNoPackageError (err: unknown): boolean {
  return util.types.isNativeError(err) && 'code' in err && (err as { code?: string }).code === 'NO_PACKAGE_IN_DEPENDENCIES'
}

Try / catch

try {
  await recursive(['update', spec], opts)
} catch (err) {
  if (isRecursiveNoPackageError(err)) {
    // fix spec/filter or add --depth before retrying; a bare retry will fail again
  } else {
    throw err
  }
}

Prevention

Generate recursive update lists from workspace manifests rather than static name lists.
Prefer `pnpm --filter <owner> update <pkg>` once you know which project owns the dependency.
Remember: depth 0 + no match anywhere = hard error by design, not a no-op.

When it happens

Trigger: `pnpm -r update <spec>` (cmdFullName === 'update', opts.depth === 0) where mutatedImporters ends up empty because no selected project's direct dependencies match the spec — misspelled name, package absent from every manifest, or --filter selecting projects that don't depend on it.

Common situations: Typo in the package name; assuming a dep is somewhere in the monorepo when it was removed or lives only in the lockfile; --filter patterns that exclude the projects that actually depend on the package.

Related errors

AI-assisted analysis of pnpm/pnpm@5b11d3a15b (2026-08-16). Data as JSON: /api/errors/358b934887932b9b. Report an issue: GitHub.