* feat(manager): pass extracted constraints to updateArtifacts
`extractedConstraints` were collected during extraction but only ever read
by `fetch.ts` for the lookup. At artifact time every manager had to derive
the same tool constraints a second time, and when the updated package file
no longer carried the constraint there was nothing to fall back to.
`generateBranchConfig()` now merges the `extractedConstraints` of all
upgrades of a branch onto the branch config, which reaches `updateArtifacts()`
through `patchConfigForArtifactsUpdate()`. `UpdateArtifactsConfig` declares
the field and documents what it contains.
The new `resolveToolConstraint()` helper implements the ladder once:
user `constraints` > an optional artifact-time derivation > the extracted
value. The derivation is ranked above the extracted value on purpose: it
reads the package files as the branch changed them, so poetry (python is an
updatable dependency there), composer, pipenv (`pipenv` can be a dev
package) and pep621 (`requires-python` is an updatable dependency) would
otherwise regress to a stale constraint. pipenv, pep621 uv/pdm, poetry and
composer are migrated to the helper and keep their derivation.
Behaviour change: these managers now use the extract-time constraint as a
last resort instead of running unconstrained, for example on lock file
maintenance where pipenv deletes `Pipfile.lock` before deriving.
`execute-post-upgrade-commands.ts` is unaffected: it reads
`upgrade.constraints` per upgrade, and the extracted values are kept in a
separate field rather than folded into `constraints`, so post-upgrade task
tool constraints still come from user config only.
Not migrated, because their constraints are never extracted, so the
fallback would be dead code: bundler (`ruby`/`bundler`), pixi (`pixi`),
pep621 uv (`required-version`) and npm's node ladder, whose last step
already reads `package.json` engines.
* refactor(manager): resolve tool constraints through resolveToolConstraint()
Every manager now obtains the constraint of a tool it runs through
`resolveToolConstraint()` instead of reading `config.constraints` itself, so
the precedence "user config, then a value derived from the updated files, then
the constraints collected during extraction" applies everywhere. The helper
treats an empty string as not set at every step and accepts the
`PostUpdateConfig` shape, whose `constraints` may be `null`.
Behaviour changes that go beyond the new fallback to extracted constraints:
- `mix` applies its hardcoded erlang default only after the extracted
constraint, so an erlang version collected at extraction can win over it.
- `kustomize` decides `HELM_EXPERIMENTAL_OCI` from the fully resolved helm
constraint; `generateHelmEnvs()` takes that value instead of the config.
- `npm` (yarn): an upgrade of yarn without a new value now consults the user
constraint before deriving one from package.json or the lock file.
- The "Using <tool> constraint from config" debug lines in bundler, composer,
copier and pip-compile are gone, as the helper is the only reader of the
config now.
Helpers that read the config synchronously became async: bundler
`getBundlerConstraint()`, copier `getPythonVersionConstraint()` and
`getCopierVersionConstraint()`, pip-compile `get*VersionConstraint()` and
`getToolVersionConstraint()`, gomod `deriveGoToolchainConstraints()` and
`getUpdateImportPathCmds()`, mise `getMiseLockToolConstraints()`. composer
`getPhpConstraint()` is removed.
Each converted manager has a test showing the extracted constraint reaching
the executed tool, and, where a derive callback exists, that the derived value
still wins over it.
* refactor(linters): add prefer-resolve-tool-constraint rule
Reports member reads and destructuring of `constraints` and
`extractedConstraints` from a manager config in `lib/modules/manager/**`, so
that tool constraints are resolved through `resolveToolConstraint()` in
`lib/modules/manager/util.ts` only. Writes and the same properties on package
files, which extraction has to populate, are not reported. The helper itself
and spec files are exempt in `.oxlintrc.json`.
* refactor(manager): inline thin resolveToolConstraint wrappers
Drop copier/utils.ts and the pip-compile getPipToolsVersionConstraint /
getUvVersionConstraint helpers, which only forwarded to
resolveToolConstraint(). Callers now call it directly.
* docs(development): note lock file maintenance in tool constraints section
* refactor(manager): address review on tool constraint resolution
composer only runs extractConstraints() when a user constraint is missing,
via Lazy. UpdateArtifactsConfig no longer re-declares constraints and
extractedConstraints, which ToolConstraintsConfig already provides.
We dropped the "bot" from our terminology long ago, but it looks like
we've got some outdated docs + code that reference it.
We should remove this to keep things consistent.
A `fix`, as we're changing the commit author's name, and log lines.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Adds a custom oxlint rule renovate/v8-ignore-no-count that flags the
count form '/* v8 ignore next <N> */'. The count is not honored by
vitest's ast-v8-to-istanbul hint parser, which captures only the
keyword (if/else/next/file); 'next' always exempts exactly the next
AST node. Trailing counts therefore suggest a line range that is never
applied and mislead readers.
The rule is autofixable (drops the count, preserving actual behavior)
and has been applied to all existing occurrences.
* docs: correct `onboardingConfig` example
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: correct `module.exports` syntax
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: completely skip `doc-fence-check` on code blocks only used for synatx highlighting
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: skip schema validation on non-config snippets
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* chore(tools/doc-fence-check): validate JSONC and Javascript code blocks
To further ensure that our documentation is well-formed, we can validate
that JSONC and Javascript code blocks are well-formed syntactically, and
are valid Renovate configuration.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* chore(tools/doc-fence-check): allow opting out of syntax validation
On top of schema validation wanting to be disabled, we should also
support disabling the syntax validation, in the case that we're using
`json` code blocks for syntax highlighting, but they're not necessarily
well-formed JSON.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: use `json` syntax highlighting
As `jsonc` doesn't seem to exist in Material for MkDocs.
As it's only for syntax highlighting, we need to opt out of validation.
* tsc
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As it doesn't work, as commits from `github-actions[bot]` can't be used
to trigger CI, and we don't want to use a PAT (as it'll then shows as
an author on PRs).
* docs(next-major): update links to Renovate 44 examples
After the inadvertent release of Renovate 44, we still need to follow
post-release actions, so we may as well keep these updated.
* docs(next-major): add reference to major version bump in docs
* feat(git): validate length commit shas
* test: adapt test mocks
* chore: update import paths
* feat(git): make the validation more strict and support repositories using sha256
* test: add fakeSha function for deterministic git commit shas in tests
* ci: add agent instructions and ClaudeCode hooks
* refactor: rename start-check and use schemas
* fix: remove redundant flow diagram
* refactor: add block utility
* docs: add reference to development documentation
* ci: add pretooluse hook
* test: remove unnecessary schema tests
* ci: add --all flag run fixer and linters in a single command
* ci: switch stop hook to `pnpm check --all`
* refactor: use simple git
* refactor: use zod/v4
* ci: prevent usages of pnpm vitest
* ci: add must read and code example for codeBlock
* fixup! simplegit by allowing user pagers and editors
* ci(agent hooks): run installs on worktree changes
* docs: shorten description
* chore: remove additional new line at the end
* explicitly fail if parsing fails
* fix: rename to kebabcase
* docs: reduce commands highlighted for local dev
* 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 `{ ... }`
* chore: move from volta.sh to mise
* !fixup chore: move from volta.sh to mise
* Update mise.toml
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* docs: explicitly document `depTypes` each manager supports
A long-standing question we receive is "what `depTypes` can I match
against in my project".
Although the best recommendation we usually have is "check the
`packageFiles with updates" log line (as a very key log line for users),
we can go one step further and try and create a stronger contract.
To do this, I've used Claude Sonnet 4.6 to work through the codebase,
determine areas that a `depType` is set in a manager (statically or
dynamically) and generate a structured, typed, means to document how
they're used.
Through a few iterations of the process, and attempts at human-written
documentation, we've settled on:
- prioritising autogenerated documentation (for humans to read) to note
what `depTypes` are known, and what they are
- `knownDepTypes`, to describe any known, static, `depType`s and their
human-readable meaning
- with the `prettyDepType`, if used
- `supportsDynamicDepTypesNote`, to add a Markdown note to the generated
documentation
While here, we also:
- make sure to note this in the "adding a new package manager"
documentation
- remove any hand-written references to `depTypes` in each manager's
documentation page
- correct the Gleam `depTypes`
- make sure to use the `knownDepTypes`'s `prettyDepType` definition if
we know it, for a given `depType`
The descriptions have been generated by Claude Sonnet, with some
human-written tweaks where appropriate.
[0]: https://github.com/renovatebot/renovate/discussions/15176
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! docs: explicitly document `depTypes` each manager supports
* docs(manager): display `depTypes` documentation if none present
For consistency, and to make it more explicit.
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
In shared preset repositories, some users will use a mix of Inherit
Config and Repo Config options with the existing JSON Schema.
As part of Renovate 43, we're removing the ability for any global
options to be usable in Repo Config, which would also mean that it's now
either a case of "ignoring warnings in my editor" and "using Global
Config JSON Schema", which isn't a great option.
We can instead create a third JSON Schema, one which is focussed on
shared presets that can include Inherit Config options.
This makes it clear that the repo config's JSON Schema should not be
used for anything Inherit Config.
* base: pile foundation
* refactor(tools): Split check.ts into modular components
- Separate files for types, coverage, git, tui, execution, test-filter
- Fix signal handler timing (register at module load)
- Export getMatchingShards/getTestPatternsForShards from test-shards.ts
Sebastian Poxhofer