* test(manager): replace file snapshots with explicit assertions
* test(manager): replace inline snapshots with explicit assertions
* test(manager): assert on relevant sections instead of full bodies
* test(manager): drop assertions implied by full equality
* test(manager): address review feedback
* test(manager): assert depType and versioning in the regex matcher
* ci(linter): add renovate/codeblock-in-spec-fixtures rule
Add a custom oxlint rule that requires the codeBlock (or stripIndent)
template helper from common-tags for multi-line string fixtures in spec
files (enabled for **/*.spec.ts and test/** only).
The rule only flags shapes whose value can round-trip through the
common-tags helpers unchanged, since both codeBlock and stripIndent trim
the end result and strip the shortest line indentation:
- only literals spanning multiple source lines are flagged (escaped \n
one-liners are left alone: tagging them is not value-preserving in
general and gains nothing)
- values with leading/trailing whitespace (e.g. fixtures ending in a
newline) are not flagged
- tagged templates, describe/it titles, and inline snapshot arguments
are skipped
All 55 pre-existing violations (22 files) were fixed with a one-off
codemod that re-emits each fixture indented to the statement depth and
verifies value preservation by evaluating codeBlock on the rewritten
template (substitutions kept as opaque placeholders). One site
(pip_requirements/artifacts.spec.ts) mixes line continuations with
escaped newlines and was tagged verbatim instead of re-indented.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* ci(linter): address review findings
Make getSimpleRequirementsFile in pip-compile/extract.spec.ts
value-preserving again: tagging the whole template with codeBlock
trimmed the trailing blank line when deps is empty (the headerOnly.txt
case), silently changing the fixture from ending in '#\n\n' to '#'.
Tag only the static header and append the deps section via a
single-line template, which reproduces the original string exactly
for both empty and non-empty deps (verified by executing old vs new
in node).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* chore: migrate from zod/v3 to zod/v4
This commit contains the logic changes
* chore: migrate imports from zod/v3 to zod/v4
This contains import updates and adds explicit record keys as zod/v4 requires these now
* ci: enforce usage of zod/v4
* 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>
Moves datasource, manager, platform and versioning code from lib/ into new lib/modules/
BREAKING CHANGE: External tools must update paths to datasource, manager, platform and versioning
Sebastian Poxhofer