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
- Run `mise lock --upgrade` at the monorepo root, as the error instructs, to bring all lockfiles to the same version
- Upgrade mise everywhere (CI, teammates) so all subprojects are relocked consistently, then commit the relocked files
- 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
- Run `mise lock --upgrade` at the monorepo root after any mise upgrade
- Keep one mise version across all subprojects and CI
- Watch for lockfile_version drift in code review
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
- unsupported lockfile version {lockfile_version}; this mise s
- {}@{} is not in the lockfile hint: {hint}
- cached rustc output directory has unsupported entries
- unrecognized provenance table format in lockfile: {:?}
- unsupported lockfile format {}
AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09).
Data as JSON: /api/errors/df02310851888dba.
Report an issue: GitHub.