mise lock silently keeps stale version for npm: backend tools when npm CLI is not installed

[zeitlinger]

Summary

When running mise lock <npm-tool> on a host without node/npm installed, the npm backend's _list_remote_versions fails with No such file or directory (os error 2). The error is logged as a WARN, the tool is silently dropped from the resolved toolset, and mise lock writes the lockfile without updating the npm tool's version — even though the user pinned an exact version in mise.toml.

This breaks Renovate's automated mise lockfile updates: Renovate bumps the toml version, runs mise lock <tool>, and commits a lockfile where the npm tool's version field is left at the old value. CI consuming the lockfile then fails with <pkg>@<new-version> is not in the lockfile.

Reproduction

# mise.toml
[tools]
"npm:renovate" = "43.220.0"

# Lock initial version (requires npm + node available)
mise lock 'npm:renovate'
# mise.lock now contains:
#   [[tools."npm:renovate"]]
#   version = "43.220.0"

# Bump the toml:
sed -i 's/43.220.0/43.232.0/' mise.toml

# On a host where node/npm are NOT installed (CI runner, Renovate container):
mise lock 'npm:renovate'
# Output:
#   mise WARN  Failed to resolve tool version list for npm:renovate:
#     [mise.toml] npm:renovate@43.232.0: No such file or directory (os error 2)
#   ✓ Lockfile written

cat mise.lock | grep -A1 npm:renovate
# version = "43.220.0"   ← STILL OLD

Same symptom for unfiltered mise lock — the npm:renovate lockfile entry is deleted entirely as "stale".

Mise version

2026.6.12 linux-x64 (also reproduces on 2026.6.10).

Why I think this is a bug

For an exact version in mise.toml ("npm:renovate" = "43.232.0"), mise lock doesn't actually need to enumerate remote versions — the version is already known. Calling _list_remote_versions (which shells out to npm view <pkg> versions time --json) is unnecessary and turns a missing npm CLI into a silent failure.

Real-world impact

Renovate's mise lockfile-update integration runs mise lock <updated-tool> inside Renovate's container. That container has mise but not node/npm. Every Renovate PR that bumps an npm:-backend tool produces a broken lockfile and fails CI.

Example: prometheus/client_java#2239 — Renovate bumps npm:renovate 43.220.0 → 43.232.0 in mise.toml, but mise.lock retains 43.220.0, breaking CI.

Suggested direction

Two options I see:

1. In the npm backend, skip _list_remote_versions (and the ensure_npm_for_version_check dep check) when the requested version is an exact pin — fall through to lock-only metadata that doesn't need the npm CLI.
2. In mise lock, when a tool resolves successfully via mise.toml's exact version, fall back to using the toml version for the lock entry even if the remote version list lookup fails.

Happy to put up a PR if you can confirm preferred direction.

[risu729]

For an exact version in mise.toml ("npm:renovate" = "43.232.0"), mise lock doesn't actually need to enumerate remote versions — the version is already known.

I might understand it wrongly, but I believe mise doesn't know if it's an actual version or not until resolving the version with remote version lists.

This should be fixed in Renovate. npm and other external CLIs should be added to toolConstraints. I'm working on it now.

Also, I'm not sure if mise lock silent failure is a design decision or not; the code seems so but I don't really understand the point.

[risu729]

Opened a Renovate PR for the toolConstraints side of this: renovatebot/renovate#44174

It installs node, npm, golang, and ruby alongside mise during lockfile updates so npm/go/gem backends can resolve remote versions when binarySource=install. I have not tested it against a real repository yet — only local unit tests and code inspection.

The silent stale-lock behavior on missing npm is still worth discussing on the mise side; this PR only addresses the Renovate container gap.

This comment was generated by an AI coding assistant.