jdx/mise · error · eyre::Report

deps provider '{}' depends on unknown provider '{}'

Error message

deps provider '{}' depends on unknown provider '{}'

What it means

`DepsOrdering::new` (src/deps/deps_ordering.rs:7) validates the deps-provider dependency list before building the graph: every id named in a provider's `depends` must be among the provider ids passed in. An unknown reference would make topological ordering impossible, so it bails naming both the referencing and the unknown provider.

Source

Thrown at src/deps/deps_ordering.rs:23

/// Manages a dependency graph of deps providers for execution scheduling.
/// Thin wrapper around `DepsGraph<String, String>` with deps-specific
/// validation and error messages.
#[derive(Debug)]
pub struct DepsOrdering {
    inner: DepsGraph<String, String>,
}

impl DepsOrdering {
    /// Creates a new DepsOrdering from a list of (provider_id, depends) tuples.
    pub fn new(providers: &[(String, Vec<String>)]) -> Result<Self> {
        // Validate that all deps reference known providers before building the graph
        let known: std::collections::HashSet<&str> =
            providers.iter().map(|(id, _)| id.as_str()).collect();
        for (id, deps) in providers {
            for dep in deps {
                if !known.contains(dep.as_str()) {
                    bail!(
                        "deps provider '{}' depends on unknown provider '{}'",
                        id,
                        dep
                    );
                }
            }
        }

        let nodes: Vec<(String, String)> = providers
            .iter()
            .map(|(id, _)| (id.clone(), id.clone()))
            .collect();

        let edges: Vec<(String, String)> = providers
            .iter()
            .flat_map(|(id, deps)| deps.iter().map(move |dep| (id.clone(), dep.clone())))
            .collect();

View on GitHub (pinned to 9dcfcaa0dc)

Solutions

  1. Fix the id inside `depends` to exactly match a configured provider id (case-sensitive)
  2. If the dependency is intentional, add/enable the missing provider's config so its id is present in the set
  3. Remove the `depends` entry if the ordering constraint is not actually needed

Example fix

# before
[deps.providers.npm]
depends = ['npx']   # no provider named 'npx'

# after
[deps.providers.npm]
depends = ['node']  # id that actually exists
Defensive patterns

Strategy: validation

Validate before calling

# lint deps providers: every depends target must be a defined provider id
import tomllib, sys
cfg = tomllib.load(open("mise.toml", "rb"))
providers = cfg.get("deps", {}).get("providers", {})
for pid, p in providers.items():
    for dep in p.get("depends", []):
        if dep not in providers:
            sys.exit(f"{pid} depends on unknown provider {dep!r}")

Prevention

When it happens

Trigger: Configuring deps providers with `depends` — e.g. `[deps.providers.<id>.depends]` listing another provider id — where the referenced id is not in the provider set being built: typo, case mismatch, or a provider whose config is not loaded/enabled in that environment.

Common situations: Typos in provider ids (`npx` vs `npm`); depends referencing a provider defined in a different config layer (global vs project) that is not active; renaming a provider id without updating depends entries; disabling a provider but leaving others depending on it.

Related errors


AI-assisted analysis of jdx/mise@9dcfcaa0dc (2026-08-17). Data as JSON: /api/errors/285d8d3f99d8214c. Report an issue: GitHub.