fix(templates): move generator dependency ranges with the dependabot wave (#4098) - #4099
Merged
Merged
Conversation
…wave (#4098) The 2026-08-10 dependabot wave bumped this repo's own manifests but not the ranges hard-coded in the scaffold generators, breaking two anchor ratchets and turning `Test (shard 1/4)` and `Test (shard 2/4)` red on every PR off main. Re-anchors three ranges (the third was invisible: the anchor test aborts at its first mismatch, and `lucide-react` sorts before `vite`): - `lucide-react` ^1.28.0 -> ^1.29.0 (app-generator routed deps, in-repo anchor) - `vite` ^8.2.0 -> ^8.2.1 (scaffold-dependencies, root anchor) - `vite` ^8.2.0 -> ^8.2.1 (create-plugin templates, root anchor) Also de-fossilises a hard-coded `'^1.28.0'` assertion in app-generator.test.ts that duplicated the anchor rule pointing the other way -- it went red on the correct fix. It now reads the same in-repo anchor. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017Qqyix2QcnpUC9XeYVDzx3
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4098
This morning's dependabot wave (07:45–08:03Z) moved this repo's own manifests but not the ranges hard-coded in the scaffold generators — dependabot does not know the templates exist. Two anchor ratchets went red on every PR branched off current
main.Premise re-verified
Both reported failures reproduce on unmodified
origin/main(361dfdc01):Direction confirmed from the ratchets' own documentation rather than assumed —
templates.test.tsstates it outright: "Bumping an in-repo manifest and leaving the template behind is the drift this test exists to catch — updatesrc/templates.tsin the same PR." Templates follow the repo, not the reverse.The sweep found a third drift
Each ratchet aborts at its first failing assertion, so each file reports one drift however many it has. Rather than fix-and-re-run, I replicated both anchor rules in a throwaway script and judged all 21 anchored ranges across all four generator maps at once:
lucide-react^1.28.0^1.29.0app-generator.tsrouted deps (in-repo)vite^8.2.0^8.2.1create-plugin/templates.ts(root)vite^8.2.0^8.2.1cli/utils/scaffold-dependencies.ts(root)The third was invisible because
lucide-reactsorts beforeviteinDEPENDENCY_ANCHORS, so the CLI test never reached it. Fixing only the two named ranges would have turned shard 1 red again on the very next lap. The other 18 anchored ranges are already correct, and the wave's other bumps (shiki, maplibre-gl, react-hook-form, next) are not declared by any generator, so no ratchet points at them.lucide-react^1.29.0is unanimous across all 23 in-repo manifests that declare it; rootviteis^8.2.1.Reverse verification
Predicted before running, and the direction is plain red — this rule compares a generated string against a repo fact, so there is no schema underneath to re-judge the same input differently (the file says as much). Restoring only the third, previously-invisible drift:
That is the second red lap this PR avoids, made visible.
One test line changed, and why
app-generator.test.ts:1082assertedexpect(manifest.dependencies?.['lucide-react']).toBe('^1.28.0')— a hard-coded second copy of the anchor rule pointing the other way, which went red the moment the template was moved onto the repo's real range, i.e. it scored a correct fix as a regression. It now reads the sameinRepoRangesOfanchor the rest of the file uses, so it cannot fossilise again. No assertion strength is lost: it still judges the manifest actually written to disk.Verification
pnpm test --shard=1/4→Test Files 289 passed (289),Tests 3599 passed | 1 skippedpnpm test --shard=2/4→Test Files 289 passed (289),Tests 3569 passedBoth were
1 failed | 288 passed (289)onmain, so each shard is green exactly where the issue reported it red.pnpm exec vitest run packages/cli/ packages/create-plugin/→5 passed (5),116 passedtype-check(both packages) → cleanlint(both packages) → 0 errors (15 pre-existing warnings in untouched files)node scripts/check-control-bytes.mjs→ OKChangeset:
patchfor@object-ui/cliand@object-ui/create-plugin. Both are published and in thefixedrelease group, and the change is user-visible — it alters thepackage.jsona scaffolded project receives.Out of scope
The issue's durable question — whether a dependabot bump touching a mirrored range could update the template in the same PR or fail its own CI — is a workflow change beyond this card and is left for triage. Filed nothing new: the sweep turned up no defect outside the three ranges above.
Generated by Claude Code