* 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()`.
* fix(vulnerabilities): scope Go stdlib OSV remediation to the `toolchain` directive
The module `go` directive was already excluded from OSV alerts, but the toolchain
rule still matched it via shared datasource/packageName and go-mod-directive ranges.
* fix(vulnerabilities): scope OSV remediation rules to the vulnerable depType
Remediation rules are generated per dependency. When that dep has a depType,
constrain the rule so it cannot match another dep that shares datasource and
packageName.
* fix(vulnerabilities): set matchDepTypes only for Go toolchain OSV rules
A generic matchDepTypes would stop an npm `dependencies` rule from also
matching `overrides` of the same package. Only the existing toolchain path
sets depType on the generated rule.
Allow osvVulnerabilityAlerts to match OSV sub-ecosystems such as
Packagist:https://packages.drupal.org/8, based on #40004. Adds a
negative test so unrelated prefixes like PackagistSomething do not match.
Co-authored-by: Stephan Zeidler <stephan@ramsalt.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
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>
* 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
As noted in #43304, when using `osvVulnerabilityAlerts`, we can
sometimes produce an `allowedVersions` that is valid for the ecosystem,
but without setting the `versioning`, we produce an invalid rule, which
then results in a `config-validation` result, breaking any updates on
the repo.
We should therefore wire in the default `versioning` for the given
datasource.
* fix(workers/repository): don't include `skipReason`'d dependencies in flattened updates
When we're preparing the final, flattened, list of branches to prepare
updates for, we're not filtering out any dependencies that have a
`skipReason` in them.
In the case that, as part of future changes like #42510, a `skipReason`
may be added after the `lookup` phase, we can still get PRs raised even
when they shouldn't be.
We already filter out `enabled=false`, so we should make sure to also
filter anything with a `skipReason`.
* feat(osv): mark malicious packages with `skipReason`s
As part of current ongoing supply chain attacks, there have been cases
where Renovate updates packages to a malicious version.
We'll be introducing a more in-depth means to surface these, including
from different API sources, as part of the Enrichment functionality,
but in the short-term we can utilise osv.dev's ingestion of OpenSSF's
Malicious Packages data.
To do this, we need to:
- look for any `MAL-` advisories
- match it against the current dependency's version, and if affected, mark it
as `skipReason: malicious-version-in-use` (which will be unset in
the `lookup()` function, so we still perform updates
- match it against the dependency's available updates, and if any are
affected, mark the dependency
as `skipReason: malicious-update-proposed`
* fixup! feat(osv): mark malicious packages with `skipReason`s
* fixup! feat(osv): mark malicious packages with `skipReason`s
* test(workers/repository): add missing coverage
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
* chore: simplify type
* wip-opus
* Revert "wip-opus"
This reverts commit e7b5f297c9.
* simplify
* sq
* sq
* fixup
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
As part of the addition of the new Enrichment modules, we should perform
a prefactor that'll introduce a shared helper for the how we translate
an "Ecosystem" according to OSV with a datasource that Renovate
understands.
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
As part of the addition of the new Enrichment modules, we should perform
a prefactor that'll introduce helper methods that can be used across
both GitHub and OSV Vulnerability Alerts.
Because each module uses a slightly different input (Datasource ID or an
"Ecosystem" according to OSV) we need to handle both types of inputs.
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
Sebastian Poxhofer