pnpm lockfile dependency {name:?} at {version:?} has no pack

Error message

pnpm lockfile dependency {name:?} at {version:?} has no package snapshot

What it means

resolve_package_keys maps a dependency name+version to entries in the lockfile's packages/importers snapshots by matching keys like `name@version` (with several prefix variants). If no snapshot key matches after trying all forms, mise cannot link the dependency into the workspace graph and fails fast.

Source

Thrown at src/task/workspace/node.rs:444

    }
    let packages = candidates
        .into_iter()
        .flat_map(|candidate| {
            available
                .iter()
                .filter(move |package| {
                    *package == &candidate
                        || package
                            .strip_prefix(&candidate)
                            .is_some_and(|suffix| suffix.starts_with('('))
                })
                .cloned()
        })
        .collect::<BTreeSet<_>>();
    if !packages.is_empty() {
        return Ok(packages.into_iter().collect());
    }
    eyre::bail!("pnpm lockfile dependency {name:?} at {version:?} has no package snapshot")
}

fn workspace_tasks(
    manifest: &PackageJson,
    package_manager: &str,
    source: &Path,
    turbo: Option<&TurboJson>,
    workspace_root: &Path,
) -> BTreeMap<String, WorkspaceTask> {
    manifest
        .scripts
        .iter()
        .map(|(name, script)| {
            let command = shell_words::join([package_manager, "run", name, "--"]);
            (
                name.clone(),
                WorkspaceTask {
                    command,

View on GitHub (pinned to afd2eddd3a)

Solutions

Run `pnpm install` to resynchronize pnpm-lock.yaml so every referenced dependency has a packages snapshot
Verify the lockfile contains a `packages:` entry matching `name@version` for the offending dependency (check for alias forms like `npm:pkg@version`)
Delete pnpm-lock.yaml and regenerate if entries appear inconsistent after a pnpm major-version upgrade

Example fix

// before: dependency references version absent from packages
// after running `pnpm install`, lockfile contains:
packages:
  left-pad@1.3.0:
    resolution: {integrity: sha512-...}

Defensive patterns

Strategy: fallback

Validate before calling

// verify snapshot presence before resolution
const key = `${name}@${version}`;
if (!(key in lockfile.packages)) console.warn(`missing snapshot for ${key}; run pnpm install`);

Try / catch

catch (e) { if (String(e).includes('has no package snapshot')) { execSync('pnpm install'); retry(); } else throw e; }

Prevention

Commit lockfiles together with package.json changes
Run pnpm install after any dependency change before running mise tasks
Watch for aliased deps (npm:...) which snapshot under different keys

When it happens

Trigger: Calling dependency_package_keys on a pnpm-lock.yaml whose packages: section lacks an entry for the resolved `name@version` — e.g. the dependency was removed from packages but is still referenced, an alias/peer dep whose snapshot key uses a different form, or a truncated lockfile.

Common situations: Stale lockfiles after dependency upgrades; peer dependencies or aliased packages (`npm:name@x`) recorded differently than the lookup expects; pnpm store prune or partial checkout dropping packages entries; lockfile format drift between pnpm major versions.

Understand the failure class

Background: "Not found" and "does not exist" errors: why "Task not found", "No such folder", and "Can't find" fire when a lookup comes back empty — this error's family across 14 libraries.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/951e302873a4270f. Report an issue: GitHub.