jdx/mise · error

backend does not support version_order

Error message

{} backend does not support version_order

What it means

The default Backend::version_order implementation rejects any request that sets a `version_order` tool option, because only backends that explicitly opt in support reordering of remote versions. This keeps tools with opaque (non-semver) version schemes source-ordered by default. It throws when the user sets version_order for a backend that has not overridden this method.

Solutions

1. Remove the `version_order` option from the tool's config for this backend.
2. Check whether the backend has opted into version_order support (overrides fn version_order); only set the option for backends that do.
3. If you maintain a backend and want semver ordering, override version_order in your Backend impl instead of relying on the default.

Example fix

// before (mise.toml)
[tools]
"npm:somepkg" = { version = "latest", version_order = "semver" }

// after
[tools]
"npm:somepkg" = "latest"

// shell: before committing config
mise config get ./mise.toml | grep version_order  # ensure only set for backends that support it
grep -rn 'fn version_order' src/backend/ | grep -v 'mod.rs'  # list opted-in backends

When it happens

Trigger: Setting `version_order = "semver"` (or any value) in tool options (mise.toml tool config or MISE_ env) for a tool whose Backend does not override version_order; calling version_order() with ToolVersionOptions containing the "version_order" key on a non-opted-in backend.

Common situations: A developer adds `[tools] "npm:foo" = { version = "latest", version_order = "semver" }` to mise.toml but the npm backend has not enabled version_order support; copying a version_order option from one tool's config to another that doesn't support it.

Related errors

• version_order must be "source" or "semver"
• a provided source resolves to a path
• additional asset ' ' is not an archive
• agent ' ' `start_calendar_interval. ` must be between and
• agent ' ' `start_calendar_interval` must set at least one…

AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17). Data as JSON: /api/errors/f5d9d00384dd7a51. Report an issue: GitHub.

Appendix: source

Thrown at src/backend/mod.rs:4191

    /// (`1.0.0-rc1`, `1.0.0-dev.5`, ...). Callers that have opted into
    /// pre-releases pass `false` to keep those tags in the match set.
    fn fuzzy_match_filter(
        &self,
        versions: Vec<String>,
        query: &str,
        filter_prereleases: bool,
    ) -> Vec<String> {
        fuzzy_match_versions(versions, query, filter_prereleases)
    }

    /// Select the ordering policy supported by this backend.
    ///
    /// Backends must opt in explicitly before `version_order` can affect remote
    /// version listing or resolution. This keeps opaque version schemes
    /// source-ordered by default.
    fn version_order(&self, opts: &ToolVersionOptions) -> eyre::Result<VersionOrder> {
        if opts.opts.contains_key("version_order") {
            bail!("{} backend does not support version_order", self.get_type())
        }
        Ok(VersionOrder::Source)
    }

    /// The key of the remote-version cache entry these listing options select.
    async fn remote_version_cache_context_for(
        &self,
        config: &Arc<Config>,
        listing_opts: &ToolVersionOptions,
        has_local_version_listing_override: bool,
    ) -> eyre::Result<Option<String>> {
        // The listing-relevant options shape the cached list, so they belong in its key.
        // Only local overrides count: a registry-supplied value is identical for everyone, so
        // one entry is correct for it, and leaving it out keeps the shared versions host
        // available for the default case.
        let opt_context = has_local_version_listing_override.then(|| {
            listing_option_digest(listing_opts, self.remote_version_listing_tool_option_keys())
        });

View on GitHub (pinned to 533346cc37)