Synchronize patch publishes across @joint/* runtime packages so Renovate grouping works

[aqeelat]

Context: I opened renovatebot/renovate#44729 to add @joint/* to Renovate's monorepo repoGroups, so consumers using multiple @joint/* packages get their updates in a single PR. A Renovate maintainer (viceice) blocked it with the Immortal PRs concern, which is now empirically validated:

• On 2026-07-07, six runtime packages published 4.3.0 together, then @joint/react shipped 4.3.1 alone ~6 hours later.
• The other five stayed at 4.3.0.

repoGroups is keyed by sourceUrl and can't distinguish patch from minor/major releases. When one package in the group publishes a solo patch, grouped consumers get a "monorepo update" PR that refreshes on every subsequent solo patch and never converges until every sibling catches up.

The package ranges themselves permit patch-level independence (@joint/core: ~4.3.0 and ^4.3.0 both accept any 4.3.x), and the dev tools (@joint/cli, @joint/eslint-config, @joint/vitest-plugin-mock-svg) are correctly on independent 0.x tracks. So the coupling is real at minor/major level but solo patches are technically supported — which is exactly what breaks Renovate grouping.

Ask: for the runtime packages (@joint/core, @joint/react, @joint/layout-directed-graph, @joint/layout-msagl, @joint/decorators, and the upcoming @joint/shapes-general*), would you consider synchronizing patch publishes — i.e. when one needs a patch, bump and republish all siblings at the same version even if only one has code changes? This unblocks Renovate consumers without changing any code/range semantics.

A deeper alternative would be moving @joint/core from dependencies to peerDependencies in the runtime packages, which is the more conventional library-monorepo pattern and lets consumers own the core version directly. But that's a breaking change requiring a major bump; the synchronized-publish approach gets the consumer ergonomics today.

[kumilingus]

Thanks for the write-up. Looked into it.

We don't want to sync-publish patches across the runtime packages. Bumping every sibling when one changes leaves a trail of empty releases with "no changes" changelogs, and it compounds: one @joint/react fix would force @joint/core, the layout packages, and @joint/decorators to republish every time. Not worth it to work around a consumer-side config issue.

And it is a config issue. The immortal PR happens when @joint/* is registered as a Renovate monorepo group, which forces lockstep versions. Once one sibling is ahead (@joint/react 4.3.1, rest at 4.3.0) the group reads as inconsistent and the PR never settles.

Batch the scope with groupName instead, and don't register it as a monorepo:

{
  "packageRules": [
    {
      "matchPackageNames": ["/^@joint//"],
      "groupName": "joint",
      "rangeStrategy": "replace"
    }
  ]
}

groupName puts all @joint/* updates in one PR. rangeStrategy: "replace" only rewrites a range when the new version is outside it, so a 4.3.1 that already satisfies ^4.3.0 won't churn the branch. Keeping it in the rule scopes it to @joint/* only. Avoid "bump", which rewrites ranges on every release and is the usual cause of PRs that never converge.

Tested it on a repo pinned to your exact case (one package a patch ahead of its siblings): Renovate opens a single grouped PR bumping only the package that changed, and it merges fine. https://github.com/kumilingus/joint-renovate-test

Longer term we're considering moving @joint/core to peerDependencies, which hands version control back to you and avoids two copies of core in a bundle. That's a breaking change, so it'd land in the next major.

Full disclosure: I'm not a Renovate user. I worked this out with Claude from the docs plus that one test repo, so treat it as a starting point rather than the final word. If you've seen cases where groupName alone still produces immortal PRs, or the monorepo diagnosis is wrong, correct me.