Dependabot cannot land a bundled miro dependency bump: the committed dist artifact needs a manual regenerate

[kyle-sexton]

What

Any Dependabot bump touching a bundled, import-reachable runtime dependency of the miro
plugin lands red and stays red until a human regenerates plugins/miro/dist/index.min.js by hand.
Dependabot rewrites package.json and package-lock.json and nothing else, so the committed
bundle keeps describing the previous dependency tree.

Observed on #1952 (@modelcontextprotocol/sdk ^1.29.0 → ^1.30.0). The PR's entire diff against
main was the two manifest files; verify-bundle failed with:

dist/index.min.js is stale — run `npm run bundle` and commit the result.

The PR sat open from 2026-08-05 to 2026-08-09 in that state. It merged only after a manual
npm run bundle and a commit of the regenerated artifact.

Why the bundle is committed at all

Not incidental — plugins/miro/build.mjs states the contract in its header: plugin install copies
the directory verbatim and runs no build step, so dist/index.min.js IS the artifact consumers
execute. verify-bundle (node build.mjs --check) rebuilds in memory and compares byte-for-byte
against the committed file, which is what makes the check trustworthy and also what makes it fail
closed on any drift.

Both properties are correct. The gap is that the one actor who opens these PRs cannot satisfy the
check.

Scope — which bumps are affected

Only bumps that are BOTH bundled and import-reachable. Evidence for the boundary:

• Affected: @modelcontextprotocol/sdk, and by the same reasoning the other entries under
  plugins/miro/package.json dependencies (@mirohq/miro-api, zod).
• Not affected: dev-only and unreachable-transitive bumps pass cleanly. chore(deps): bump hono from 4.12.29 to 4.13.0 in /plugins/miro #1905 bumped hono on
  main with green CI and no dist regeneration, because nothing imports it into the bundle.

So this is not "every miro bump" — it is a specific, enumerable class, which is what makes a
targeted fix possible.

Candidate remedies

Not ranked; each has a real cost and the choice is a design decision.

1. CI regenerates and commits. A workflow step runs npm run bundle and pushes the artifact
   back to the PR branch when it drifts. Closes the gap without changing the distribution model.
   Cost: CI gains write access to PR branches, and a bot-authored commit lands on a bot-authored PR
   — worth weighing against this org's posture on what may push.
2. dist leaves version control, with plugin install performing a build. Removes the class of
   defect entirely. Cost: contradicts the copies-verbatim-no-build-step install contract that
   build.mjs documents, so it is a distribution-model change, not a CI tweak.
3. Bot-facing documentation only — a note that these bumps need a manual regenerate. Cheapest,
   and it does not fix anything; it converts a silent stall into a documented one.

Option 1 is the only one that keeps both current invariants (committed artifact, byte-exact check)
while removing the human step. Option 2 is the only one that removes the invariant that creates the
problem. Recommend deciding between those two rather than defaulting to 3.

Why this is worth tracking rather than absorbing

The failure is invisible until someone reads the log: the PR shows a red required check with no
indication that the remedy is a build command rather than a code fix. #1952 idled four days. The
next such bump will idle the same way, and the plugin's dependencies include an MCP SDK that ships
frequently.

Related

• chore(deps): bump the npm-minor-patch group in /plugins/miro with 3 updates #1952 — the bump that surfaced it; merged with a manually regenerated bundle (e87e5932).
• chore(deps): bump hono from 4.12.29 to 4.13.0 in /plugins/miro #1905 — a hono bump that passed without regeneration, establishing the reachability boundary.
• plugins/miro/build.mjs — the header comment stating the committed-artifact contract.