pnpm lockfile dependency

Error message

pnpm lockfile dependency {name:?} has no resolvable version

What it means

While walking a pnpm lockfile to compute reachable packages for workspace tasks, mise resolves each dependency entry to a version string. pnpm v9+ lockfiles can store importers/dependency entries where neither a direct string version nor a nested "version" field exists (e.g. link:/workspace-style or peer-only entries). Mise bails because it cannot map the dependency to a package snapshot.

Solutions

Run `pnpm install` to regenerate a complete, valid lockfile with resolved versions.
Replace file:/tarball or link: deps with regular registry versions where feasible.
Upgrade pnpm so workspace links are recorded with resolvable snapshots.
Inspect the offending dependency name in the error and fix or remove that entry.

Example fix

// pnpm-lock.yaml (before)
deps:
  my-pkg:
    specifier: ^1.0.0
// after (regenerated by pnpm install)
deps:
  my-pkg:
    specifier: ^1.0.0
    version: 1.2.3

Defensive patterns

Strategy: validation

Validate before calling

// before relying on mise workspace tasks:
// ensure lockfile deps are resolvable
const deps = lock.importers.flatMap(i => ({...i.dependencies, ...i.devDependencies}));
for (const [name, v] of Object.entries(deps)) {
  const version = typeof v === 'string' ? v : v?.version;
  if (!version) console.warn(`dep ${name} has no resolvable version`);
}

Try / catch

try {
  mise('run', 'task');
} catch (e) {
  if (/has no resolvable version/.test(e.message)) {
    execSync('pnpm install', { stdio: 'inherit' });
  } else throw e;
}

Prevention

Run `pnpm install` after editing package.json so the lockfile stays consistent.
Avoid link:/file:/tarball deps in packages mise analyzes for workspace tasks.
Never hand-edit pnpm-lock.yaml.

When it happens

Trigger: dependency_package_keys encounters a dependency in an importer block whose value is neither a version string nor an object with a version key — e.g. file:/ tarball deps, link: workspace deps, or a corrupted lockfile entry.

Common situations: pnpm lockfileVersion 9 with workspace link: dependencies; dependencies pointing at local tarballs (file:./pkg.tgz); git or patch-protocol deps lacking a resolved version field; hand-edited lockfiles.

Understand the failure class

Background: Record Not Found Errors: "not found", RecordNotFound, and "was not found" — what they mean and how to fix them — this error's family across 28 libraries.

Related errors

AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17). Data as JSON: /api/errors/7d7500178a2137dc. Report an issue: GitHub.

Appendix: source

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

    }
    Ok(reachable)
}

fn dependency_package_keys(node: &Value, available: &BTreeSet<String>) -> Result<Vec<String>> {
    let mut packages = Vec::new();
    for field in ["dependencies", "devDependencies", "optionalDependencies"] {
        let Some(dependencies) = node.get(field).and_then(Value::as_mapping) else {
            continue;
        };
        for (name, value) in dependencies {
            let Some(name) = name.as_str() else {
                continue;
            };
            let version = value
                .as_str()
                .or_else(|| value.get("version").and_then(Value::as_str));
            let Some(version) = version else {
                eyre::bail!("pnpm lockfile dependency {name:?} has no resolvable version");
            };
            packages.extend(resolve_package_keys(name, version, available)?);
        }
    }
    Ok(packages)
}

fn resolve_package_keys(
    name: &str,
    version: &str,
    available: &BTreeSet<String>,
) -> Result<Vec<String>> {
    if ["link:", "workspace:", "file:"]
        .iter()
        .any(|prefix| version.starts_with(prefix))
    {
        return Ok(Vec::new());
    }

View on GitHub (pinned to 533346cc37)