Files
renovate/lib/workers
Sebastian Poxhofer fd4eb7bfbd refactor(workers): normalise depName and packageName once after extraction (#46156)
* refactor(workers): assemble the per-dependency lookup config in one place

The extracted constraints were merged with the same spread twice in
`fetch.ts`, once per package file and once per dependency, and
`constraintsVersioning` only at the package file level. Both levels now go
through `mergeExtractedConstraints()`, and `PackageDependency` gained the
`constraintsVersioning` which only `PackageFileContent` had.

The datasource `defaultConfig` was applied in `fetch.ts` before the lookup and
again in `flatten.ts` afterwards, because `Object.assign(dep, upd)` only copies
the `UpdateResult` fields back onto the dependency. Both call
`applyDatasourceDefaultConfig()` now. Persisting the merged defaults on the
dependency instead would have moved them into another precedence layer of
`flatten.ts`, which merges them over the update config, so the defaults keep
being applied twice.

Behaviour change: a `constraintsVersioning` set on a dependency by a manager is
now honoured, below the package file and the repository config. No manager sets
it yet.

* refactor(workers): normalise depName and packageName once after extraction

`massageDepNames()` only copied `packageName` into a missing `depName`, so the
opposite fallback was applied again in `fetch()` and re-derived at seven worker
call sites.

Extraction now normalises both directions once, via an exported
`normalizeDepNames()`, which also takes over the `depName` trimming that
`fetch()` used to do. Every consumer downstream of extraction reads the field it
wants directly: `fetch()`, the dependency dashboard, the auto-replace deps
signature, the attestation PR note, the commit body table, the OSV lookup and
the rollback PR note.

Both places which re-extract a package file outside the extract phase -
`checkBranchDepsMatchBaseDeps()` and `checkForPendingVersions()` - call
`normalizeDepNames()` on the freshly parsed deps first, so their names stay
comparable with the deps that went through extraction.

In-manager fallbacks are left alone: they run before extraction normalises the
names.

No behaviour change.

* Apply suggestion from @secustor

* refactor(workers): assemble the per-dependency lookup config in one place

The extracted constraints were merged with the same spread twice in
`fetch.ts`, once per package file and once per dependency, and
`constraintsVersioning` only at the package file level. Both levels now go
through `mergeExtractedConstraints()`, and `PackageDependency` gained the
`constraintsVersioning` which only `PackageFileContent` had.

The datasource `defaultConfig` was applied in `fetch.ts` before the lookup and
again in `flatten.ts` afterwards, because `Object.assign(dep, upd)` only copies
the `UpdateResult` fields back onto the dependency. Both call
`applyDatasourceDefaultConfig()` now. Persisting the merged defaults on the
dependency instead would have moved them into another precedence layer of
`flatten.ts`, which merges them over the update config, so the defaults keep
being applied twice.

Behaviour change: a `constraintsVersioning` set on a dependency by a manager is
now honoured, below the package file and the repository config. No manager sets
it yet.

* refactor(config): move applyDatasourceDefaultConfig next to getManagerConfig

Importing config/utils from the datasource module made tools/generate-imports.mjs load config options before manager-default-configs.generated.ts exists, breaking install in CI.

* test(manager/gomod): normalise dep names before running the lookup

* test(manager/gomod): explain why dep names are normalised

* test(workers): give the jsonata base dep a packageName like extraction does
2026-09-29 07:38:08 +00:00
..