Group @gtbuchanan/hk-config with hk in the shared Renovate preset

[gtbuchanan]

Problem

The shared Renovate preset (default.json) groups all jdx/hk updates under groupName: "hk" (mise tool + the amends URL in *.pkl + the .chezmoidata version comment), but @gtbuchanan/hk-config is not part of that group. Because hk and hk-config are mutually coupled, splitting them into separate PRs produces intermediate states that are broken in both directions.

hk-config's Defaults.pkl is built against a specific hk Config/Builtins version, and a consumer's hk.pkl pins the hk version twice — the amends URL and the installed binary (mise). So the two deps have to move together:

• hk bumped, hk-config held → the newer hk binary can reject the older preset (e.g. hk 1.51 rejects match_any combined with a top-level types, which the hk-config 0.2.0 preset emitted).
• hk-config bumped, hk held → the preset targets schema/hook behavior the older binary and older amends pin don't provide.

Both PRs also edit the same hk.pkl, so whichever merges first forces the other to rebase.

Seen in gtbuchanan/dotfiles

Renovate opened two separate PRs — hk → v1.53.0 and @gtbuchanan/hk-config → v0.2.2 — that could not be merged independently. They had to be combined into a single hand-authored change that bumped both together and validated the real combination in one CI run.

Proposed fix

Fold @gtbuchanan/hk-config into the existing hk group so both bumps share one branch/PR and get validated together:

{
  "description": "Group @gtbuchanan/hk-config with hk — hk-config's Defaults.pkl is built against a specific hk Config/Builtins version, so the amends pin and the import must move together",
  "groupName": "hk",
  "matchDepNames": ["@gtbuchanan/hk-config"]
}

Match by dep name, not by matchSourceUrls: https://github.com/gtbuchanan/tooling — tooling is a monorepo that also publishes @gtbuchanan/cli, so a source-URL match would wrongly rope the CLI into the hk group. (The exact matcher should line up with whatever the hk-config custom manager emits as its depName.)

Caveats

• Grouping does not enforce version compatibility — Renovate will still bump hk to its own latest alongside hk-config's latest. If a given pair is incompatible, CI remains the safety net, same as any grouped update. What grouping removes is the mutually-broken intermediate states and the hk.pkl textual conflict.
• No throttling downside: a lone hk (or lone hk-config) update still ships on its own under the hk branch; they only combine when both are pending.
• No-op in tooling itself, which imports Defaults.pkl by relative path, so it's safe in the shared preset and every consumer benefits.