* refactor(linters): add prefer-coerce-array rule
Refs #45217
`x ?? []` and `coerceArray(x)` say the same thing, but only the second
one is searchable and consistent. The rule flags a `??` whose default is
a bare `[]` literal; a non-empty default or an asserted `([] as Foo[])`
still passes.
Applying it across `lib/` surfaced three spots the helper cannot cover,
which keep `?? []` with a disable comment or a narrower fix:
- `package-files.ts` destructures a tuple, which `coerceArray()` widens
- `generate.spec.ts` defaults `matchAll()`, an iterator rather than an array
- `mise/upgradeable-tooling.ts` declares a `Record` return, so its
`?? []` fallback was wrong to begin with and becomes `coerceObject()`
* refactor(platform/github): hoist the GHE version header lookup
`Object.entries(...).find()` returns a tuple, and defaulting it with
`?? []` only to destructure the second element reads as an array
default when it is not one. Name the found entry instead, which drops
the `?? []` rather than routing a tuple through `coerceArray()`.
The containous/traefik repository was renamed to traefik/traefik in 2020. GitHub still redirects, but PR release notes render the old organization name.
* feat(presets): add @oxlint/* packages to packages:linters
Groups oxlint plugin packages together with oxlint itself.
* feat(presets): add @oxlint/plugins to monorepo:oxlint
* test(presets): update linters snapshots for @oxlint/**
* feat(config): add `overrideDescription` option
Presets which extend many other presets used an `ignoreDeps: []` sentinel
to keep their own one-line summary in the onboarding PR instead of one line
per extended preset. Replace that hack with an explicit `overrideDescription`
option, which is consumed and removed while presets are resolved.
The resolved descriptions are unchanged. Repositories which set
`ignoreDeps: []` in their own config no longer lose all preset descriptions
in their onboarding PR.
* fixup! feat(config): add `overrideDescription` option
* fixup! feat(config): add `overrideDescription` option
* fixup! feat(config): add `overrideDescription` option
* feat(replacements): add replacements for dev-facing Comet packages
* fix: add current version matcher to rules
* fix: change dev-process-manager current version to >=3.0.0
* fix(preset/monorepo): re-add old facebook/react URL
I'd missed this from 61e4c9c2d1, which
leads to old PRs no longer being grouped, which is not correct.
* fixup! fix(preset/monorepo): re-add old facebook/react URL
fix(data): update react and react-native source URLs to react/react org
The react and react-native repositories moved from the facebook org to
the react org on GitHub
See https://github.com/renovatebot/renovate/discussions/44772
Make the `checkKeysSorted` first-keys assertion unconditional by
defaulting the expected prefix to an empty array, so `expect` is no
longer nested inside an `if`.
Part of #43845
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* docs: skip validation on JSON files that aren't Renovate config
As part of future changes, we'll enable validation on all JSON code
snippets to run Config Validation.
Before we do that, we should opt-out JSON snippets that aren't anything
related to Renovate config.
* docs: don't validate invalid Renovate config
As it's intentionally referencing a manager that doesn't exist.
* docs: don't validate partial Renovate config
As part of future changes, we'll enable validation on all JSON code
snippets to run Config Validation.
There are several code snippets we have that are part of a Renovate JSON,
but it doesn't make sense to convert these to a fully passing config, as
it'd reduce clarity on what we're trying to explain.
* docs: convert `baseBranchPatterns` snippets to code blocks
So we can validate them.
* docs: make sure that `datasourceTemplate` is set
So this passes validation.
* docs: clarify that `force` is global config
As it may not be clear, so we can make it extra clear with a `.js` file,
and note that it's global self-hosted config.
* docs: make sure `packageRules` is an array
* docs: `matchBaseBranches` needs `baseBranchPatterns` to be set
* docs: correct typo for `prBodyColumns`
* docs: mark global config snippets as such
As part of future changes, we'll use this to detect whether it's global
self-hosted configuration.
* docs: make sure `packageRules` wraps its children
* docs: add `allowedHeaders`
* docs: ignore deprecation warnings
As part of future changes, we'll use this to note that we don't care
about the validation warnings.
* docs: make sure `customManagers` wraps its children
* docs: make sure `fleet` wraps its children
* docs: validate JSON snippets are valid Renovate config
To make sure that we're always presenting valid JSON configuration to
our users, we can validate them as part of `check-fenced-code`.
As well as configuration errors we can warn for warnings, but allow code
blocks to opt-out, for instance when there's a known deprecation
affecting the code block.
We need to make sure to set `allowedEnv` for various code snippets that
reference environment variables.
* docs(development): document fenced code block checks
* docs: wrap `configType` and `ignoreConfigWarnings` in `{ ... }`
As otherwise we see build failures i.e.
WARNING - Doc file 'modules/platform/gitlab/index.md' contains a link
'../../../self-hosted-configuration.md#autodiscoverrepoorder', but the doc
'self-hosted-configuration.md' does not contain an anchor '#autodiscoverrepoorder'.
This needs to be wrapped alongside all other options like `title`.
* fixup! docs: wrap `configType` and `ignoreConfigWarnings` in `{ ... }`
* ci: add local mkdocs-admonitions plugin for prettier to allow admonition preservation
* docs: remove uses of `prettier-ignore` for admonitions
* test: rather use await expect
* chore: use named group exclusively
As a way of indicating how fresh our list of supported tools in the
registry is, we can make sure we populate the version into a note above
the table.
We can extract a type to make it easier to reference the parsed JSON
file.
This requires a small tweak to handle `content`'s table insertion.
* 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>
github-actions[bot]