mirror of
https://github.com/renovatebot/renovate.git
synced 2026-10-26 15:31:53 +00:00
fd4eb7bfbd
* 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