Files
renovate/lib/data
Jamie Tanna 2bd478fff4 feat(mise): automagically support all tools through Mise Registry (#42783)
* feat(mise): automagically support all tools through Mise Registry

As noted in #42250, we should try and auto-support tools from Mise where
possible.

Similar to other areas of the codebase, we should use the "static data"
pattern, and periodically sync the `mise registry --json` output with
`lib/data/mise-registry.json`, and then auto-detect the tools that we
support through the known backends the tools support.

This takes lower precedence than existing in-code tool definitions, so
we can still provide an "override" if we can support lookups or version
extraction more appropriately.

Because we now have many more tools we (mostly) support out-of-the-box,
we need to provide an improved documentation page, and:

- only link to tools we have an explicit tools URL for
- note where a backend may not be supported

To automate the updating of this data, we:

- make sure we have `mise` in GitHub Actions, before we run
- don't pin the `mise` version to make sure that we're always seeing the
  latest supported tools
- make sure the commits generated are now `feat(...)`, as they introduce
  functionality changes (in the case new tool(s) are supported)

This improves support from ~170 tool short names to just over 1000.

Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>

* refactor: use Typescript

As we can now, we should.

Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>

* refactor(tools/static-data): use Zod schemas for parsing

Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>

* refactor(mise): use Zod for types

Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>

* chore(mise): prefer the GitHub backend over other sources

As we generally prefer it as a project, we should automagically use that
when looking at a mise registry entry.

With help from GPT-4.1 to write the `sortBackend` function.

Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>

* test: ignore else coverage

* docs(mise): preference of `github` backend

* docs(mise): auto-link autogenerated tools

* perf(mise): sort registry only once

* refactor(mise): transform when parsing

Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>

* refactor: use `execa`

* perf(mise): read the Mise registry once

* perf(mise): pre-transform

---------

Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
2026-04-28 08:56:09 +00:00
..

Introduction

The lib/data folder has all our crowdsourced data files. This readme explains what each file is used for.

Summary

File What is the file about?
monorepo.json Group related packages into a single PR.
replacements.json Rename old packages to new replacement.
changelog-urls.json Tell Renovate where to find changelogs.
source-urls.json Tell Renovate the source URL of packages.
node-schedule.json Node.js versioning schedule.
mise-registry.json Mise tool registry: short names mapped to backends.

The monorepo.json file has all the monorepo presets.

Monorepo presets group related packages, so they are updated with a single Renovate PR.

!!! note We only accept monorepos when packages are released together. So they should have all the same version or they strictly need to be merged together. Otherwise those groupings would cause immortal PR's. Please add that information with links to source for validation.

Ways to group packages

There are three ways to group packages:

Group packages Method
From the same source repository. repoGroups
From the same organization. orgGroups
Based on name patterns or prefixes. patternGroups

Rename old packages (replacements.json)

The replacements.json file has all the replacement presets.

When a package gets renamed, you need to tell Renovate:

  • the datasource of the package → matchDatasources
  • the old package name → matchPackageNames
  • the new package name → replacementName
  • the last version available for the old package name → matchCurrentVersion
  • the first version available for the new package name → replacementVersion

You can omit replacementVersion if the current version is the same as the new version.

Example:

{
  "matchCurrentVersion": ">=3.10.3",
  "matchDatasources": ["npm"],
  "matchPackageNames": [
    "apollo-server",
    "apollo-server-core",
    "apollo-server-express"
  ],
  "replacementName": "@apollo/server",
  "replacementVersion": "4.0.0"
}

Tell Renovate where to find changelogs (changelog-urls.json)

The changelog-urls.json has all the changelog information.

Renovate nearly always finds, and displays, the changelog for a package update automatically.

Usually, the API for the package to be updated gives Renovate the correct info. If this does not happen, for whatever reason, Renovate can not show the changelog.

You can use these config options to let Renovate find the correct changelog:

Read the Renovate docs, key concepts page for changelogs to learn more about how Renovate fetches and displays changelogs.

To locate the changelogs, Renovate requires:

  • the name of the package (packageName)
  • the datasource of the package
  • the URL to the changelog file (changelogUrl)

Example: For the zone.js package, the changelog URL is https://github.com/angular/angular/blob/master/packages/zone.js/CHANGELOG.md. This will be added to the npm group in the changelog-urls.json file since the package's datasource is npm.

Tell Renovate where to find source urls (source-urls.json)

The source-urls.json has the information on source URL of multiple packages.

Renovate nearly always finds, and displays, the source for a package update automatically. Usually, the API for the package to be updated gives Renovate the correct info. If this does not happen, for whatever reason, Renovate can not link to the source of the package and might not be able to lookup changelogs.

To check if Renovate can find the source URLs for your package:

  1. Find the datasource for your package.
  2. Read the Renovate docs for the datasource.
  3. Look for a table in the docs that shows if the datasource returns source URLs.

If Renovate does not find the right source URls automatically: use the sourceUrl config option.

To locate the source repository, Renovate requires:

  • the name of the package (packageName)
  • the datasource of the package
  • the URL to the source repository (sourceUrl)

Example: The source URL for the repository cypress-io/cypress is https://github.com/cypress-io/cypress. This will be added to the orb group in the source-urls.json file since the package's datasource is orb.

Node.js Versioning Schedule node-schedule.json

This file is automatically updated by a scheduled workflow. It can be manually updated by running pnpm update-static-data:node-schedule.

Mise tool registry (mise-registry.json)

This file is automatically updated by a scheduled workflow. It can be manually updated by running pnpm update-static-data:mise-registry.

It maps mise tool short names (e.g. zola) to their available backends (e.g. ["aqua:getzola/zola", "asdf:salasrod/asdf-zola"]). The data is generated from mise registry --json using the mise CLI.

This enables Renovate to automatically support all tools in the mise registry without manual updates.