feat(lint): add `types-location` rule and enable it for `lib/modules`
Reviewers consistently ask for exported types to be moved into a
colocated `types.ts`. Add a `renovate/types-location` oxlint rule that
reports `export interface` / `export type` declarations outside such a
file, and turn it on across `lib/modules`.
Re-exports (`export type { X }`, `export type *`), file-local types, and
values (enums, classes, functions) are left alone. `schema.ts` files and
`schema/` directories are excluded via config, matching how
`zod-schema-location` is configured — inferred types belong next to the
schema they are derived from.
Relocating the 87 existing violations means:
- new `types.ts` files for the modules that had none
- `terragrunt/common.ts` folded into its `types.ts`, as it held nothing
else
- `RangeBound` in `versioning/gradle/compare.ts` un-exported, since only
a file-local interface referenced it
- `bazel-module/parser/fragments.ts` split from its inferred types, which
now live in `parser/types.ts` and infer through a namespace import so
each schema keeps its merged name
As noted in #43761, we had recently set `CI=true` for the Renovate and
Containerbase orgs on Mend-hosted apps due to a pnpm v11 requirement:
ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY Aborted removal of
modules directory due to no TTY
If you are running pnpm in CI, set the CI environment variable to
"true", or set "confirmModulesPurge" to "false".
Similarly in #43606, it was noted that we should do this for `mise lock`
to mark the workspace as "trusted".
Although we went with a different situation, there will be cases where
this is useful for tools being executed, for instance when we invoke `yarn`.
We also make sure to keep our documentation up-to-date as we add to the
specific overrides.
With help from Claude Sonnet and Opus to:
- perform some of the mechanical updates as part of this change
- ensure that the Docker sidecar always has `hardcodedProcessEnv` passed
into it
- catch a needed change to `exposeAllEnv` handling
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* 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
As found with recent changes to the Terraform manager, although we
generally have `lockFileMaintenance` being executed by an external
package manager being invoked by `exec(...)`, there are a few package
managers that do not do so.
To make it very clear how this happens, we can add a new field to the
Manager API, which will provide a means to document this.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As noted in #30714, and to make the Minimum Release Age page a
"one-stop-shop", we can generate the documentation accordingly.
Using an orange "maybe" for support helps nudge folks to checking which
registry they're using, and noting that it still doesn't necessarily
work, even if the Datasource supports it.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* feat(lint): add renovate/zod-schema-location and renovate/prefer-json-pipe rules
Backlog item #23: reviewers repeatedly ask for consistent Zod schema
structure. Two new oxlint JS-plugin rules, both at "warn":
- renovate/zod-schema-location flags `export const X = <zod schema>` at
module scope in lib/modules/**/ files that aren't schema.ts (or a
colocated schema/ directory), reusing the leftmost-identifier schema
detection from zod-schema-naming.js / prefer-nullish-util.js. Only
exported top-level schemas are flagged — non-exported ones are treated
as intentionally local/trivial (e.g. tightly coupled to file-local
helpers), which keeps the rule's signal high.
- renovate/prefer-json-pipe flags `Schema.parse(JSON.parse(x))` /
`Schema.safeParse(JSON.parse(x))` and suggests `Json.pipe(Schema)` from
lib/util/schema-utils instead.
A third mined slice (require a matching `z.infer` type export for every
exported schema) was evaluated and skipped: ~275+ exported schema-like
consts in schema.ts files vs. 231 existing z.infer exports repo-wide is
too high a mismatch to flag mechanically without heavy per-site
judgment, so it would be mostly false positives.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: fix a clean subset of renovate/zod-schema-location and renovate/prefer-json-pipe violations
renovate/prefer-json-pipe: fixed all 5 safe `.parse(JSON.parse(...))`
call sites (bazel datasource, generate-mise-registry script, a hook
spec) by switching to `Json.pipe(Schema).parse(...)`. Left the 2
`.safeParse(JSON.parse(...))` sites (pretooluse-check.ts,
github-query-items.ts) unfixed: JSON.parse throwing before safeParse is
reached today crashes the script, whereas Json.pipe folds the bad-JSON
case into a graceful `{ success: false }`, which is an observable
behavior change, not just a mechanical rewrite.
renovate/zod-schema-location: fixed the one clean, self-contained
violation (platform/github's GithubIssue schema, moved into the
already-existing platform/github/schema.ts) as a representative
example. Left the other 20: they require moving exported schemas out of
files where they're built from local helper functions/config tables
(manager/github-actions/community.ts) or restructuring an entire
directory into a new schema.ts with import-graph updates across many
files (manager/bazel/rules/*.ts, manager/bazel-module/parser/*.ts) —
real refactors needing per-site judgment, not mechanical fixes.
Both rules stay at "warn": renovate/prefer-json-pipe has 2 remaining
violations that shouldn't be auto-fixed, and renovate/zod-schema-location
has 20.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: resolve remaining prefer-json-pipe and zod-schema-location findings
- github-actions: move the derived `CommunityActions` union into the
existing colocated `schema.ts`; the action config table and the
`actionSchema` builder stay in `community.ts` and are now exported.
- tools/docs: fold `JSON.parse` + `safeParse`/rethrow of the `gh` CLI
output into `Json.pipe(...)`. Invalid JSON now surfaces as a ZodError
instead of a SyntaxError; the only consumer catches generically, so
behavior is preserved.
- tools/agents/hooks: keep `JSON.parse` + `safeParse` with a reasoned
disable comment — hook scripts must stay dependency-light, and the
`Json` helper lives in lib/util/schema-utils, which drags in the full
lib import graph (logger, yaml, toml).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* feat(lint): enforce zod-schema-location and prefer-json-pipe as errors
Narrow `renovate/zod-schema-location` to files whose directory already
contains a colocated `schema.ts`. The mined reviewer feedback ("move
this to schema.ts") presumes the module follows that convention and the
schema leaked into a logic file. Modules that deliberately export
schemas from differently-named schema-only files — bazel `rules/*.ts`
Target schemas, bazel-module `parser/fragments.ts` — are a different,
accepted layout, not "schema mixed into logic", and are no longer
flagged.
With that narrowing and the preceding migrations, both rules are clean
repo-wide, so promote them from "warn" to "error".
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: drop GithubIssue re-export from issue.ts
Consumers now import the schema directly from schema.ts.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(lint): register zod-schema-location rule
The rule registration was lost while merging main, so oxlint failed to
parse .oxlintrc.json with "Rule 'zod-schema-location' not found in plugin
'renovate'". Re-add the import and rules entry, and restore alphabetical
ordering for prefer-json-pipe.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(lint): allow sync fs in zod-schema-location rule
ESLint rules execute synchronously, so the sibling `schema.ts` lookup
cannot use async fs. Silence `no-sync` with a justification.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* docs(manager): make sure that Supported Datasources are de-duped and sorted
As noted in #44764, we otherwise end up with a lot of duplicated
entries for `renovate-config`.
We can also sort them to make ti a slightly more readable list.
* chore(manager/renovate-config): dedupe `supportedDatasources`
Enable no-else-return (with allowElseIf: false) and unicorn/no-lonely-if
as errors in .oxlintrc.json and fix all 131 pre-existing violations
(91 no-else-return, 40 unicorn/no-lonely-if) across 98 files.
The no-else-return violations were fixed with the oxlint autofix
(iterated to a fixpoint, plus two else-if chains that required
--fix-dangerously) followed by Prettier formatting. One comment dropped
by the autofix in lib/modules/manager/pub/artifacts.ts was restored
manually. The unicorn/no-lonely-if violations were merged by hand,
preserving comments and coverage-ignore hints.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
- Convert `param: T | undefined = undefined` to optional `param?: T`.
- Drop dead `= false` defaults on the required cache-provider options.
- Make `GraphqlPaginatedContent.nodes/edges` optional so the `= []`
fallbacks (load-bearing for partial GraphQL connections) are valid.
- Type the unchecked `default_branch` response field as optional so
the `'HEAD'` fallback is retained.
- Drop `tag = undefined` from the Forgejo/Gitea/GitLab preset configs.
Part of #43845
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* feat: add generic statusCheckWhen option to control any renovate status check
Replace the artifacts-specific `artifactsCheckWhen` option with a generic
`statusCheckWhen` object that can control when ANY Renovate status check is
emitted. Keys mirror `statusCheckNames`: `artifactError`, `configValidation`,
`mergeConfidence`, `minimumReleaseAge`.
Each key accepts: "always" | "never" | "failed"
- always: set check on every commit (green on success, red on failure)
- never: skip the check entirely
- failed: only set the check when there is a failure (silent on success)
Default values preserve existing behavior:
- artifactError: "failed" (only report failures, as before)
- configValidation: "always"
- mergeConfidence: "always"
- minimumReleaseAge: "always"
The defaults table in docs is autogenerated from the option's `default`
field via `tools/docs` so the docs cannot drift from the source of truth.
Logging is gated so that "skipping" debug lines only fire when there is
something to skip (errors / status set), keeping logs quiet on every
branch run when a check is set to "never".
Example configuration:
```json
{
"statusCheckWhen": {
"artifactError": "always",
"mergeConfidence": "never"
}
}
```
Signed-off-by: Pierluigi Lenoci <pierluigilenoci@gmail.com>
* refactor(docs): address viceice review — single replace marker, coerceObject, simplify replaceContent call
- Use single replace marker instead of begin/end pair in docs and config.ts
- Use coerceObject from lib/util/object.ts instead of manual (val ?? {}) as Type
- Refactor replaceContent call to match upstream API signature (string, not object)
Signed-off-by: Pierluigi Lenoci <pierluigilenoci@gmail.com>
* fix: fix test for never mode with no errors and format docs
- Add missing config.artifactErrors = [] in test that checks
'skips status entirely when mode is never with no errors' (beforeEach
sets artifactErrors to [{fileName: 'some'}], test needs no errors)
- Reformat note block in docs from 4-space to 2-space indent to match
prettier formatting (custom mkdocs-admonitions plugin expectation)
Signed-off-by: Pierluigi Lenoci <pierluigilenoci@gmail.com>
---------
Signed-off-by: Pierluigi Lenoci <pierluigilenoci@gmail.com>
* docs(manger/github-actions): reword "community actions" section
As some follow-ups to 27a3f5871f, we
can slightly reword the intro to add some more information about what
these target.
* docs(manager/github-actions): document why there may not be a `packageName`
* docs(manager/github-actions): generate a table for Actions and their `with`s
To provide further clarity on how each of the Actions' `with`s are used,
we can make this more explicit in our autogenerated docs, providing:
- which field(s) are extracted, taken from their Zod schema (with help
from Claude Opus to extract this)
- note the dependency updating, and where it may be determined from the
given `withSchema`
Co-authored-by: Claude Opus 4.7 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 4.7 <jamie.tanna+claude-code@mend.io>
In the case of a config option that has both `allowedValues` and is
templateable - such as `bumpVersions.bumpType` - we should relax the
generated JSON schema to not restrict the exact value.
As part of recent work around environment variable handling, it's clear
we should provide more user-facing documentation on how environment
variables are handled, and which are passed to child processes by
default.
We can create a "deep dive" page for this, with an autogenerated list of
the environment variables in `basicEnvVars` that are always passed to
child processes, if they're set.
We can also point self-hosted administrators and users alike to the
options they have to control this, too.
With help from GPT-4.1 for case-insensitive sorting.
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>
* docs(config): don't trim newline after generated config filenames
Otherwise there's no newline before the next sentence.
* docs(config): correct usage of JSON5 presets
* docs(config): rewrite overview section
- introduce a linkable section for "what filenames are supported"
- correct the usage of "config help" discussions
- keep precedence/ordering in a single paragraph
* fixup! docs(config): rewrite overview section
* docs: ensure 2 spaces used for generated admonitions
As a follow-up to 4b0146ab7b and
1844916259b6dc17f532e491eb93f6116327c324., this correctly renders
admonitions with 2 spaces (1 indent).
* fixup! docs: use 2-space indentation for Markdown (#43537)
Plus using 3-space for mixed-style `<ul>` and `<ol>`s.
* fixup! docs: use 2-space indentation for Markdown (#43537)
As otherwise it breaks the rendering of the table.
* docs: add "previously known as" to renamed options
To provide a more searchable set of docs in the case that we migrate a
config option, we can introduce a `previouslyKnownAs` field in the
resulting generated documentation.
This allows someone to search for the previous name and find the new
option name.
For now we'll also not implement `RENOVATE_X_` variables.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! docs: add "previously known as" to renamed options
This is a more involved change, which requires we handle the custom
coersion for `RENOVATE_REPOSITORY_CACHE_FORCE_LOCAL`.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Instead of having a warning around "this is experimental" after
scrolling down to the end of the config option's description, we can
instead make it more prominent and move them all to the top - after the
table listing - but before the main body.
At some point in the past, mise's support for the short name `kafka` was
removed.
We can warn our users that this is no longer supported, but keep our
custom logic for it, in case it returns in the future.
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.
As noted in #41214, it would be convenient to not have to manually
update this list.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* refactor(docs): don't use an `end` for autogenerated docs
As part of #42910, we wanted to avoid needing a "begin" and "end" to
each of our autogenerated docs replacements.
While looking into it, we're not actually using the "end" for anything,
so we can instead refactor this to be a single-line replacement.
To simplify the code and docs, we can remove this. At the point we need
this again, we can re-add the functionality.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! Merge remote-tracking branch 'origin/HEAD' into chore/no-replaceStop
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* docs(templates): ensure whitespace before generated list
Otherwise it doesn't render correctly as a list.
* docs(templates): sort outputted options/fields
As then it's more predictable and readable.
* docs(templates): wrap options/fields in code blocks
As then they're more clearly an option.
* supportsTemplating field
* fix ci issue
* fix ci issue
* move tip below table
* apply suggestions
* docs: show list of options that support templating
* jsodc explanations for internal fields
* add test to ensure no option that applies template.compile() missed supportsTemplating=true
* apply review suggestions
* fix bad merge
* add filePatterns and commands to the list
As part of future changes, we'll introduce coverage of all properties
under `packageRules`.
Before we do this, we should use `$ref`s to make sure that we don't
duplicate the definitions too much.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat: allow separate versioning for constraints
As noted in #31831, there are times where it can be useful to override
the version that a given datasource uses, when performing
`constraintsFiltering=strict.`
This should only be applicable to the "additional" constraints, so we
make sure to validate this.
As this is new functionality, any misconfiguration should be marked as
an error.
We can make sure to provide a real-world usecase for this (taking
inspiration from `rails`' versioning of the `rubygems` constraint).
This will be used in the future by the extraction of the `go` directive,
which requires a different versioning to the default `semver`.
* fixup! feat: allow separate versioning for constraints
* fixup! feat: allow separate versioning for constraints
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* extra-log-context
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* 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>
* docs(constraints): list the possible `constraints` and `installTools`
Now we have a stronger type for what a valid tool constraint is, and
what additional constraints are, we should be very explicit with what
each option is, and specify them in the `constraints` as well as our
`installTools` docs.
* test: add coverage
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Instead of inline documentation with JSDoc, we can use an optional
`description` field that can be accessed programatically.
This means the `description` can also be added to our JSON Schema for a
Tool, or be the only output when a non-Tool constraint, as the
description for non-Tools are more clear than the autogenerated text.
We can make sure we continue to export the known names, as well as the
full definitions.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* docs(json-schema): add `constraints` and `installTools`
This requires `toolNames` and `additionalConstraintNames` are exported
for use.
* fixup! docs(json-schema): add `constraints` and `installTools`
As they are configuration options and can be quite code-y we should
render them like this.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As noted in #42798, `platform=local` and other experimental platforms
are seeing the page for each of those platforms having duplicate
content.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* docs(mise): render sorted table of short-names for tools
As a way to improve the rendering of the large list of tools that we
support for mise-en-place, we can render them as a table.
This allows us to sort them by tool name, as well as make it clearer
which source the tool is from.
As part of future changes, we'll introduce more information and sources
of the table, so rendering them as a table will be more readable.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* docs(mise): wrap tool names in code tags
As they're generally a command.
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
To provide more programmatic means to determine what environment
variables configure Renovate configuration options - and whether they're
Repo, Inherit or Global config options - we can expose these in two
forms:
- `getEnvOptionsMap()`
- a static JSON file, `renovate-env-options.ts`
This will provide programmatic use-cases from a plain JSON file that can
be used more readily - especially as it's distributed in the docs and
built package - as well as a function that can be used by users of
Renovate-as-a-library.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
When trying to work out how Renovate's internal presets work, it can be
a little awkward trying to jump between the different `extends`, as it
requires copy-pasting and searching.
We can utilise the annotations functionality in Material for MkDocs[0]
and generate the relevant annotations for each of the `extends` that
appears.
In the case that a preset has a description (which is most of them) we
can add that for a more interesting annotation.
This requires we:
- look up the presets' `description` ahead-of-time, as the generation
process removes descriptions
- traverse the preset's `extends` and link it through to the destination
preset
- create an ordered list after the code block to note the annotations
- handle parameterised presets
[0]: https://squidfunk.github.io/mkdocs-material/reference/code-blocks/#adding-annotations
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* 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>
Editors such as VSCode will look for `markdownDescription` to render the
description, if present, and will render that as Markdown, instead of
plain text.
This also makes sure that our URL fragments should be more consistent
over the years, as duplicate names (across parent and child options)
cannot clash.
This also corrects links from the code to include the new fragment.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Sebastian Poxhofer