jdx/mise · error

cannot merge lockfile version {} from {} into lockfile versi

Error message

cannot merge lockfile version {} from {} into lockfile version {} at {}; run `mise lock --upgrade` at the monorepo root

What it means

When merging a subproject lockfile into a monorepo root lockfile, mise requires both files to share the same lockfile_version (unless the subproject is legacy version 0, which is absorbed by raising the root's version). If the versions differ otherwise, the merge is refused with guidance to run `mise lock --upgrade` at the monorepo root.

Source

Thrown at src/lockfile.rs:1766

            Lockfile::read(target).unwrap_or_else(|err| handle_lockfile_read_error(err, target));
        let subproject_lockfile = match Lockfile::read(source) {
            Ok(lockfile) => lockfile,
            Err(err) if is_not_found_report(&err) => continue,
            Err(err) => return Err(err),
        };
        if !target_existed {
            root_lockfile.lockfile_version = subproject_lockfile.lockfile_version;
        } else if root_lockfile.lockfile_version != subproject_lockfile.lockfile_version
            && allow_format_upgrade
        {
            // Keep the newer format so request bindings from either input remain
            // serialized if the subsequent rebuild fails. Entries imported from
            // version 0 remain reachable through the unbound-entry fallback.
            root_lockfile.lockfile_version = root_lockfile
                .lockfile_version
                .max(subproject_lockfile.lockfile_version);
        } else if root_lockfile.lockfile_version != subproject_lockfile.lockfile_version {
            bail!(
                "cannot merge lockfile version {} from {} into lockfile version {} at {}; run `mise lock --upgrade` at the monorepo root",
                subproject_lockfile.lockfile_version,
                display_path(source),
                root_lockfile.lockfile_version,
                display_path(target)
            );
        }
        merge_lockfile_preserving_root(&mut root_lockfile, subproject_lockfile);
        root_lockfile.save(target)?;
        if let Err(err) = fs::remove_file(source)
            && err.kind() != ErrorKind::NotFound
        {
            return Err(err.into());
        }
        migrated += 1;
    }

    if migrated > 0 {

View on GitHub (pinned to afd2eddd3a)

Solutions

  1. Run `mise lock --upgrade` at the monorepo root, as the error instructs, to bring all lockfiles to the same version
  2. Upgrade mise everywhere (CI, teammates) so all subprojects are relocked consistently, then commit the relocked files
  3. Temporarily align by regenerating the offending subproject lockfile with the same mise version as the root

Example fix

# before: root lockfile_version = 2, subproject = 3
# at monorepo root:
mise lock --upgrade
git add mise.lock && git commit
Defensive patterns

Strategy: try-catch

Validate before calling

// Before merging, check root and subproject lockfile versions match
let ver = |p: &str| -> u64 { toml::from_str::<toml::Value>(&std::fs::read_to_string(p).unwrap())
    .unwrap().get("lockfile_version").and_then(|v| v.as_integer()).unwrap_or(0) as u64 };
assert_eq!(ver("mise.lock"), ver("sub/mise.lock"), "run `mise lock --upgrade` at monorepo root");

Try / catch

match merge_lockfiles(root, sub) {
    Err(e) if e.to_string().contains("cannot merge lockfile version") => {
        // follow the remediation the error suggests
        upgrade_locks_at_root()?;
        merge_lockfiles(root, sub)?;
    }
    other => other?,
}

Prevention

When it happens

Trigger: Running a build/operation that merges subproject mise.lock files into the root lockfile while the subproject was written with a different lockfile_version than the root — e.g. one part of the monorepo was locked by a newer mise. The error reports both versions and both file paths.

Common situations: Mixed mise versions across a monorepo; a partial `mise lock` upgrade touched only some subprojects; an older checkout or submodule lockfile committed at a different format version.

Understand the failure class

Background: "is not a compatible type" / "cannot merge" errors: when a value's type doesn't match what the library requires — this error's family across 65 libraries.

Related errors


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