jdx/mise · error

mise upgrade --monorepo is not implemented yet

Error message

mise upgrade --monorepo is not implemented yet

What it means

`mise upgrade` defines a `--monorepo` clap flag explicitly labeled a placeholder (src/cli/upgrade.rs:106-108: 'Placeholder for future monorepo upgrades; mise upgrade --monorepo is not implemented yet'). Passing it makes `Upgrade::run` hit `unimplemented!()` at src/cli/upgrade.rs:163 before `Config::get()` is even awaited, so no lockfile migration, outdated scan, or install happens. The flag reserves the CLI grammar for future monorepo support only.

Source

Thrown at src/cli/upgrade.rs:163

        if self.local {
            ConfigScope::LocalOnly
        } else {
            ConfigScope::All
        }
    }

    pub async fn run(mut self) -> Result<()> {
        if self.legacy_bump {
            deprecated_at!(
                "2026.8.5",
                "2027.8.5",
                "cli.upgrade.bump-l",
                "`mise upgrade -l` is deprecated. Use `mise upgrade -b` or `mise upgrade --bump` instead. After removal, `-l` will become shorthand for `--local`."
            );
            self.bump = true;
        }
        if self.monorepo {
            unimplemented!("mise upgrade --monorepo is not implemented yet");
        }
        let mut config = Config::get().await?;
        if !self.is_dry_run() {
            crate::lockfile::migrate_monorepo_lockfiles(&config)?;
        }
        let ts = ToolsetBuilder::new()
            .with_args(&self.tool)
            .with_scope(self.scope())
            .build(&config)
            .await?;
        // Compute before_date once to ensure consistency when using relative durations
        let before_date = self.get_before_date()?;
        let opts = ResolveOptions {
            use_locked_version: false,
            latest_versions: true,
            resolve_rolling_channels: false,
            prefer_exact_version: false,
            before_date,

View on GitHub (pinned to 6bd4a54fad)

Solutions

  1. Remove `--monorepo` and run `mise upgrade` inside each project directory; mise.lock handling already runs per config via migrate_monorepo_lockfiles
  2. Scope upgrades per project with `mise upgrade --local`, or bump ranges with `mise upgrade -b` inside each subproject
  3. Use `mise upgrade -n` (dry-run) in each subproject before real upgrades
  4. Check mise release notes / `mise --version` and adopt the flag only once monorepo support ships

Example fix

# before
mise upgrade --monorepo
# after
for d in services/*/; do (cd "$d" && mise upgrade); done
Defensive patterns

Strategy: validation

Validate before calling

# gate the flag on real support before upgrading
if mise upgrade --help 2>/dev/null | grep -q -- '--monorepo.*not implemented'; then
  for d in services/*/; do (cd "$d" && mise upgrade -n); done  # dry-run per project
else
  mise upgrade --monorepo
fi

Try / catch

# shell: fall back to per-project upgrades on the panic
out=$(mise upgrade --monorepo 2>&1)
if [ $? -ne 0 ] && printf '%s' "$out" | grep -q 'not implemented yet'; then
  for d in services/*/; do (cd "$d" && mise upgrade); done
else
  printf '%s\n' "$out"
fi

Prevention

When it happens

Trigger: Running `mise upgrade --monorepo` (or `mise up --monorepo`, since `up` is a visible alias). The panic fires immediately in `run()` after only the legacy `-l` deprecation handling, so the command aborts with exit failure and a panic message rather than upgrading anything.

Common situations: Upgrade automation written against planned monorepo functionality discussed in mise issues; shell completion surfacing the flag; lockfile-using monorepos (note `migrate_monorepo_lockfiles` exists at src/cli/upgrade.rs:167) leading users to assume the flag already works; version drift between a teammate's mise and yours.

Related errors


AI-assisted analysis of jdx/mise@6bd4a54fad (2026-08-16). Data as JSON: /api/errors/5e21ffa2aa05f866. Report an issue: GitHub.