Skip to content

Consolidate the three stalled Dependabot bumps into one lockfile regeneration #157

Description

@os-zhuang

Filed by the repo:objectos execution seat (objectstack#9831), session session_01VFwZj1a84ZxFUcWAi5H8S5, round 1, on the maintainer's instruction to clear the open PR list ("这个清单需要合并的也要合并", 2026-08-22), who then chose this route over the alternative when both were put to them.

Why this card exists rather than three merges

Three Dependabot PRs are open, all safe patch/minor bumps, all stalled:

PR Bump Declared range today
#49 react-dom 19.2.6 → 19.2.7 ^19.2.6
#46 tailwindcss 4.3.0 → 4.3.3 ^4.3.0
#50 @tailwindcss/postcss 4.3.0 → 4.3.3 ^4.3.0

They cannot be merged as they stand and cannot be rebased by this seat:

  1. All three are ~67 commits behind and conflicted. Their only check is a build from 2026-07-19, which predates both the Node floor and Ownership & freshness gates — that green certifies nothing about today's main.
  2. All three rewrite pnpm-lock.yaml, so exactly one could land per lap even with working rebases; each merge invalidates the rest.
  3. @dependabot commands cannot be issued from this tooling. A sanitizer rewrites the mention on write — two separate sessions posted the command and both were stored as ·@·d·ependabot r·ebase. This is recorded on chore(deps): bump react-dom from 19.2.6 to 19.2.7 #49; it is a tooling artefact, not a mis-typed command, and no amount of re-asking will move the bot.

One change that regenerates the lockfile once is strictly better than three sequential rebases: one CI run, one lockfile regeneration, and one production docs deploy instead of three — deploy-docs.yml fires on every pnpm-lock.yaml push to main.

Scope

apps/docs/package.json (dependencies / devDependencies only) and pnpm-lock.yaml.

Because all three declared ranges are carets that already permit their targets, the manifest edit is the small half — the substantive change is the regenerated lockfile.

⚠️ The interaction that makes this more than a version bump

main now carries a blocking unsupported rule (landed this round as ca34d36, #137/#138): every declaration's floor — >=22.12.0 — must itself satisfy every engines.node range in pnpm-lock.yaml. A regenerated lockfile can introduce a range with a hole at 22.12.0, and that now fails CI rather than passing quietly.

Before this rule existed, a dependency bump could not redden the Node floor gate. It can now. Re-running node .github/scripts/check-node-floor.mjs after the regeneration is not optional, and a red there is a real finding, not a flake.

Definition of done

  1. The three packages resolve to their target versions in pnpm-lock.yaml.
  2. engines blocks are untouched in every package.json.
  3. node .github/scripts/check-node-floor.mjs exits 0 on the regenerated lockfile.
  4. The required build job passes.

react is already ^19.2.7 on main while react-dom sits at ^19.2.6; #49 closes that pairing gap, which is the one item here with a correctness argument behind it rather than just currency.

Once landed, #46, #49 and #50 close as superseded against the commit that carries their bumps — not on a promise. #48 (@opennextjs/cloudflare) is not in scope: it upgrades the deploy adapter itself and is held on a separate question with the maintainer.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions