* feat(versioning): comparator ranges for the regex scheme
The regex versioning orders versions by the release array built from its
captured groups (major, minor, patch, build, revision) but matches every range
by exact equality, so a comparator range in `allowedVersions` (`<=1.2.3` and
friends) never resolves against a regex-versioned dependency.
Add a scheme-independent comparator parser (`generic-range.ts`) and wire it
into the regex scheme's `isValid`/`matches`/`getSatisfyingVersion`/
`minSatisfyingVersion`, evaluating each `<`, `<=`, `>`, `>=`, `=`, `==` term
through the scheme's own `_compare`. A pattern that captures a `-ee.N` suffix
as an ordered `build` component then resolves `<=X-ee.0` correctly, where npm
`semver` cannot: as a prerelease the suffix breaks the range, as build metadata
it is ignored, and a four-part release is not valid semver.
The parser defers operand validation and comparison to the caller, so it stays
independent of npm `semver` (used by the semver family) and consistent with the
scheme's own ordering. Dependency values stay exact tags, so `supportsRanges`
remains `false`.
* test(versioning): cover regex ordering by capture-group name, not position
Add a calendar-versioning case (`YYYY.DD.MM`) showing comparison follows the `major`/`minor`/`patch` capture-group names in precedence order, not their left-to-right position: naming the month `minor` and the day `patch` sorts by year, then month, then day even though the day is the middle field.
Also reword the readme, which described this as "the same capture-group ordering" and read as positional, to state the major/minor/patch precedence explicitly.
* refactor(versioning): declare RangeComparator in types.ts
The `renovate/types-location` rule requires an exported type to live in a
colocated `types.ts`, so `RangeComparator` is declared there and
`generic-range.ts` imports it.
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
* feat: add versioning for Hermit package manager
* Update lib/modules/versioning/hermit/index.ts
Co-authored-by: Jamie Magee <jamie.magee@gmail.com>
* Update lib/modules/versioning/hermit/index.ts
Co-authored-by: Jamie Magee <jamie.magee@gmail.com>
* Update index.ts index.spec.ts and readme.md according to PR comments
* fix: fix versioning test double negation and _parseVersion function which is just for testing
* fix: simplify hermit versioning implementation as suggested
* fix: use _compare to simplify versioning implementation
* fix: reword version in hermit versioning and make _isChannel & _getChannel static
* fix: remove duplicated title in test and make _config readonly
Co-authored-by: Jamie Magee <jamie.magee@gmail.com>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
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
Aaron Paterson