npm backend install fails when the project package.json declares a non-npm devEngines.packageManager with onFail: "error"

[lachieh]

Describe the bug

The npm: backend fails to install/resolve a tool when the surrounding project's package.json declares a devEngines.packageManager (or devEngines.runtime) that isn't npm/node and sets onFail: "error".

mise's npm backend resolves versions by shelling out to the system npm CLI (npm view <pkg> dist-tags --json, npm view <pkg> versions time --json). npm reads the nearest package.json and enforces its devEngines. This means that if a project declares a devDependency for bun with onFail: "error" then every call to npm in that project exits non-zero with EBADDEVENGINES so mise use npm:<pkg> / mise install npm:<pkg> fail.

Steps to reproduce

mkdir /tmp/mise-deveng && cd /tmp/mise-deveng

cat > package.json <<'EOF'
{
  "name": "repro",
  "private": true,
  "devEngines": {
    "packageManager": { "name": "bun", "version": "1", "onFail": "error" }
  }
}
EOF

cat > mise.toml <<'EOF'
[tools]
node = "24"
EOF

mise trust
mise use npm:cowsay # fails

Output (trimmed):

npm error code EBADDEVENGINES
npm error EBADDEVENGINES Invalid devEngines.packageManager
npm error EBADDEVENGINES Invalid name "bun" does not match "npm" for "packageManager"
npm error EBADDEVENGINES {
npm error EBADDEVENGINES   current: { name: 'npm', version: '11.13.0' },
npm error EBADDEVENGINES   required: { name: 'bun', version: '1', onFail: 'error' }
npm error EBADDEVENGINES }
mise ERROR Failed to install npm:cowsay@latest: command ["npm", "view", "cowsay", "dist-tags", "--json"] exited with code 1

Expected behavior

Installing a tool through the npm: backend should not be blocked by the surrounding project's devEngines.packageManager / devEngines.runtime policy. mise's npm-backed tools are mise-managed dev tooling, conceptually separate from how the project manages its own dependencies. A project that requires contributors to use bun should still be able to mise use npm:<some-cli>.

Suggested fix

Run the npm backend's internal npm invocations from a neutral working directory (or pass --prefix) so npm doesn't pick up the project's devEngines. Pointing npm at a directory without the project package.json makes the same call succeed.

Note that the npm flag --no-engine-strict / .npmrc setting npm_config_engine_strict=false does not help since that gates engines, not devEngines.

Workarounds

• Set devEngines.packageManager.onFail (and/or runtime.onFail) to "warn" instead of "error" so that npm then only warns.
  Caveat: you lose hard enforcement for actual project engines.
• Install the npm:<pkg> tool from a directory outside the project (no package.json with devEngines) then manually add the tool to the mise config within the project.

[sueun-dev]

It's npm enforcing your devEngines.packageManager on every command, including the read-only npm view that mise's npm backend uses to resolve versions. Verified: in your dir, npm view cowsay dist-tags --json exits EBADDEVENGINES, so mise use npm:<pkg> dies during resolution. The tell is in mise's source: the version-query npm view calls run in the invocation cwd with no --prefix, while the install path already isolates itself (current_dir(install_path) + --prefix). So resolution inherits your project's devEngines even though install wouldn't, that asymmetry is the bug.

Workaround that keeps onFail: "error": run mise with npm_config_force=true (e.g. npm_config_force=true mise use npm:cowsay). Verified, it lets npm view through, so resolution succeeds, without touching your file (it does disable npm's protections for that one call). The real fix is giving the version queries the same neutral cwd / --prefix the install path already uses.

[risu729]

Thanks for the clear report and repro — this was helpful.

Opened a fix in #10927: mise-owned npm view calls now use --prefix against a neutral cache dir, so project devEngines no longer blocks version resolution.

Worth noting: npm install was already ignoring the project package.json / .npmrc because it uses --prefix <install_path>. Only the metadata queries were still running against the project cwd; this PR brings them in line with install.

This comment was generated by an AI coding assistant.