chore(deps): group the node-datachannel family in Renovate and update it to v0.33.4

[dormouse-bot]

Lands the node-datachannel 0.33.2 → 0.33.4 round as one PR, and stops the next round from splitting the same way.

Why the split PRs are all red — in two different ways

Renovate splits every node-datachannel release into seven PRs — one per prebuilt platform package plus the core package — and each one is red on its own. website/scripts/generate-deps.js describes the five platforms pnpm did not install from whichever sibling it did, matching on the exact version string; that is the "optional, declared by a product root" rule in docs/specs/security-supply-chain.md -> Disclosure. The six prebuild-only PRs make it throw, so the Dependency disclosure is current step in ci.yml fails before it writes anything:

Error: "@node-datachannel/darwin-arm64" is not installed and neither is any sibling
declared beside it at the same version, so it cannot be described

The core-only PR (#647) fails differently: core installs cleanly and brings its own optionalDependencies at the new version, so each prebuild resolves twice — once from the root pin, once nested under the new core — and the regenerated snapshot carries both, which the step then rejects as a diff:

-    "version": "0.33.2",
+    "version": "0.33.2, 0.33.4",

Either way none of the seven can go green alone, and the set does not even out until all of them land together.

What this PR does

1. chore(renovate): bump the node-datachannel prebuild family as one group adds the lockstep group the family needs, in the same shape as the five that already exist for react, react-router, tailwindcss, storybook, vite, and xterm. Renovate runs Mondays (* * * * 1), so from the next run the family arrives as a single grouped PR. That grouped PR will still be red on arrival — Renovate does not run the disclosure generator, so website/src/data/dependencies-npm.json is stale until someone commits node website/scripts/generate-deps.js. The payoff of grouping is that this is one commit to clear, where a split bump throws before it can produce a snapshot at all. The rule's description says so, so the next session does not read that red as the grouping failing.

2. chore(deps): update the node-datachannel family to v0.33.4 clears the round that is already open: core plus all six prebuilds in standalone/sidecar/package.json, the lockfile, and the regenerated website/src/data/dependencies-npm.json.

The core node-datachannel package is in the group deliberately, not just the @node-datachannel/* prebuilds. It declares its own optionalDependencies at its own version, and the addon resolves its platform binary relative to its own directory — so bumping the six platform packages while core stays at 0.33.2 leaves the nested 0.33.2 binary loading and ships the sidecar-root 0.33.4 copy unused. The upstream fix the bump is for would not reach the runtime.

Supersedes

Closing as duplicates of this one: #637, #639, #640, #643, #644, #645, #647.

Why the renovate.json change was opened here rather than in a review

Three separate tend-review sessions reached this same conclusion independently — on #637, #639, and #640 — each wrote out the rule, and each declined to open it because two sibling sessions were looking at the same family at the same moment. The daily run census is where those three views meet, so this is the consolidation rather than a fourth independent derivation.

Verified rather than assumed: optionalSiblingsAtSameVersion in website/scripts/generate-deps.js is the sibling-at-same-version rule and throws otherwise; all seven split PRs report Build & Test: FAILURE; .github/renovate.json parses after the edit. pnpm test passes locally on this branch (three standalone/sidecar shell-integration cases fail identically on main on this machine — macOS's Terminal session-restore banner leaks into captured bash output — and pass on the CI runner).

🤖 Generated with Claude Code

https://claude.ai/code/session_01HHoyvmFzcmMyFbsTSp8FmL

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	cddbfd6
Status:	✅  Deploy successful!
Preview URL:	https://c37eb8b8.mouseterm.pages.dev
Branch Preview URL:	https://daily-review-runs-3485546447.mouseterm.pages.dev

View logs

[dormouse-bot]

Feedback on work in progress — the config change itself is correct, and this isn't a merge verdict. Mark the PR ready when you want the full review.

The grouping fixes the throw, but it does not make the family green on its own, and the description reads as though it does ("None of the seven can go green alone, and the set will not even out until all of them land together"). website/src/data/dependencies-npm.json carries a version field for all seven packages, and nothing regenerates it on a Renovate branch — the Dependency disclosure is current step in ci.yml runs the generator and fails on any diff under website/src/data/. So the single grouped 0.33.4 PR arrives red too, just for the stale-snapshot reason rather than the throw. The difference that matters is that a grouped PR is fixable with one node website/scripts/generate-deps.js commit, where a split one throws before it can produce a snapshot at all — that's the payoff worth stating, rather than "the set evens out."

Worth saying in the PR body, and arguably in the rule's description too, so the next session that picks up the grouped PR knows a regeneration commit is expected rather than treating the red as a regression in the grouping.

[nedtwigg]

Good catch, and it survived the rewrite — taken in fadb34c7.

You were right that the grouping alone does not make the family green: Renovate never runs generate-deps.js, so a grouped PR arrives with a stale website/src/data/dependencies-npm.json too. The rule's description now says that explicitly, along with the distinction that matters — one commit to clear, versus a split bump that throws before it can produce a snapshot at all — and the PR body says the same.

The PR itself has also grown past the config change: it now carries the 0.33.2 → 0.33.4 bump for all seven packages, the lockfile, and the regenerated disclosure, so the currently-open round is cleared rather than left for a future grouped PR. #637, #639, #640, #643, #644, #645, and #647 close as duplicates of it.

[dormouse-bot]

Feedback on work in progress, not a merge verdict — mark it ready when you want the full one.

The mechanics check out: the lockfile diff is version-only (no new transitive packages), the regenerated snapshot is what generate-deps.js produces for the six root-declared prebuilds plus core, and the new rule mirrors the five existing lockstep groups.

One correction to the reasoning both the PR body and the rule's description carry: the seven split PRs do not all fail the same way. The six prebuild PRs throw, as described — but #647, the core-only bump, does not. Its Build & Test fails on the stale-snapshot diff, because core is a plain dependency that installs fine and the six root-declared prebuilds still describe each other at 0.33.2.

What that run prints is the better argument for keeping core in the group than "ships a prebuild nothing loads", because it is observable rather than inferred: the snapshot generate-deps.js wants to write there lists every prebuild at "0.33.2, 0.33.4" — the host's prebuild resolves twice, once from the root pin and once nested under the new core, and the five absent siblings inherit that two-version set through the sibling-description path. So a core-only bump is not blocked at all; it is one commit from landing a disclosure that states the nested-vs-root split as fact on the public supply-chain page. The group rule is what prevents that, not the generator.

Suggestion inline on the description; the PR body's "Why the split PRs are all red" section needs the same split.