[ENHANCEMENT] Add dedicated channels for chromedriver

[Unknown78]

No one uses the latest canary channel of the chrome browser all the time.
It will be convenient if we could just run mise use -g chromedriver@stable

Just like mise ls-remote rust has nightly, beta and stable keyword,
I think chromedriver should also do the same, such that we also have four of these.

stable
beta
dev
canary

JSON file to crawl for the stable, beta, dev, and canary channel.
https://github.com/GoogleChromeLabs/chrome-for-testing/blob/main/data/last-known-good-versions-with-downloads.json

[risu729]

I don't think mise should add rust-style channels for chromedriver.

The plugin already lists every Chrome for Testing build. Prefix matching and pinning cover this:

mise use -g chromedriver@152
mise use -g chromedriver@152.0.7977.54

@152 resolves to the latest 152.x, which is currently Chrome Stable (152.0.7977.54). Beta is 153.x; Dev/Canary are 154.x.

Rust stable / beta / nightly are rustup channels in the rust core plugin, with rolling resolution and concrete lockfile versions. ChromeDriver does not publish those names. Google's last-known-good JSON is a side mapping, not first-class versions, so doing this properly would mean rust-like rolling channels for one registry tool.

chromedriver@latest landing on a canary-era build is because the plugin returns known-good versions newest-first, with no stable/prerelease split. That follows this API; it is not a missing channel feature.

For Selenium, chromedriver still needs to match the installed Chrome, not Google's current Stable.

AI-assisted — Tool: Cursor; model: cursor-grok-4.6-xhigh; version: unavailable.

[Unknown78]

What do you mean does not publish those names? The ,json file clearly has keys named channel and the GitHub page clearly states the channels https://googlechromelabs.github.io/chrome-for-testing/index.html

I have a vision in the future not only chromedriver is in the mise registry, but also Chrome for Testing of both chrome and chrome-headless-shell

So having a complete registry of chromedriver including its channels is a good first step for it.

[risu729]

What do you mean does not publish those names?

I mean they don't have literal stable, beta, dev, or canary. So, unlike Rust, you cannot install those versions as-is. It needs to be resolved to a concrete version.
This means you cannot see those in mise ls-remote.

What do you mean by a "complete registry"? We should not handle this in the registry. If you haven't, please have a look at https://github.com/mise-plugins/vfox-chromedriver. I don't know if jdx will accept PRs, but you can fork it; I think it's possible to support those channels as rolling releases, or tag releases as prerelease, with the current vfox plugin capabilities.

https://github.com/mise-plugins/vfox-neovim might help you!

[Unknown78]

Sorry for poor wording, I mean complete registry as in the entries in the mise ls-remote, which would requires modifying the vfox-chromedriver

---

https://github.com/mise-plugins/vfox-chromedriver/blob/main/hooks/available.lua#L10-L15

    local resp, err = http.get({
        url = "https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-downloads.json",
        headers = {
            ["Accept"] = "application/json",
        },
    })

https://github.com/mise-plugins/vfox-neovim/blob/main/hooks/available.lua#L63-L68

    local resp, err = http.get({
        url = "https://api.github.com/repos/neovim/neovim/releases",
        headers = {
            ["Accept"] = "application/vnd.github.v3+json",
        },
    })

---

The JSON format differs, as it uses the GitHub API.

Given the circumstances, could we have an entries in mise ls-remote that mirrors a concrete version, such that the plugin could also query the last-known-good-versions-with-downloads.json to obtain it?

[risu729]

Sorry, after further research, it might not be clean with the current vfox plugin system. I think you can add fake versions and treat them as rolling releases like in neovim, but it shows those fake versions (like stable in mise ls-remote, which is not ideal).
For mise ls-remote, I think you have a misunderstanding here; the vfox plugin output is the source of truth, and mise ls-remote just uses it. mise-versions.jdx.dev is just a cache.

[Unknown78]

What's your idea of ideal in this context? Is having keywrods in mise ls-remote is a bad thing?
If fake versions suffice to resolve to the correct versions of the official channel then why not? Or is there a better way?