Uh oh!
There was an error while loading. Please reload this page.
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
|
yinlianghui
marked this pull request as ready for review
August 10, 2026 08:44
Uh oh!
There was an error while loading. Please reload this page.
yinlianghui pushed a commit
that referenced
this pull request
Aug 17, 2026
…pendabot wave The scaffolded plugin's generated devDependencies declared @testing-library/jest-dom at ^7.0.0 while the repo root had moved to ^7.0.1 (#4948's dev-dependencies group), so templates.test.ts's anchor rule was red on main independently of the lucide-react drift in the previous commit. Same defect class, same wave, and the same pairing the previous occurrence of this incident was fixed as (#4098 / PR #4099 moved these two templates in one PR). Found only by sweeping the class rather than the package: the anchor rule throws on its first mismatch, so this second template reported nothing until the first was green. The doc table above the map is moved with it -- it states each anchored range, so leaving it would just relocate the fossil into a comment. Co-authored-by: Claude <noreply@anthropic.com>
akarma-synetal pushed a commit
to akarma-synetal/objectui
that referenced
this pull request
Aug 17, 2026
…ack-ai#4977) (objectstack-ai#4978) * fix(cli): catch the app-generator lucide-react range up to the workspace The routed temp app's generated manifest declared lucide-react at ^1.29.0 while all 22 sibling manifests that declare it had moved to ^1.31.0, so a generated app asked npm for an icon library older than the one every @object-ui/* package it installs alongside was built against. app-generator.test.ts derives its expectation from the in-repo range, so the drift was caught -- both pins were red. They just went red too late to stop anything: the dependency PR merged while those shards were still running, and the failure then surfaced on the merge ref of every unrelated open PR. The other 12 anchored ranges were swept against the same dependabot batch and are all in sync. Deriving the value rather than quoting it was considered and rejected; the reasoning is recorded at the call site. Fixesobjectstack-ai#4968 Co-authored-by: Claude <noreply@anthropic.com> * fix(create-plugin): move the jest-dom template range with the same dependabot wave The scaffolded plugin's generated devDependencies declared @testing-library/jest-dom at ^7.0.0 while the repo root had moved to ^7.0.1 (objectstack-ai#4948's dev-dependencies group), so templates.test.ts's anchor rule was red on main independently of the lucide-react drift in the previous commit. Same defect class, same wave, and the same pairing the previous occurrence of this incident was fixed as (objectstack-ai#4098 / PR objectstack-ai#4099 moved these two templates in one PR). Found only by sweeping the class rather than the package: the anchor rule throws on its first mismatch, so this second template reported nothing until the first was green. The doc table above the map is moved with it -- it states each anchored range, so leaving it would just relocate the fossil into a comment. Co-authored-by: Claude <noreply@anthropic.com> * fix(ga-pin): follow the quick-reference spec/client rows to GA, cite $like/$ilike as undecided Two residues of the `@objectstack/spec` 17.0.0 GA pin were red on `main` itself, so every open PR inherited a red `Test (shard 3/4)` (objectui#4977). 1. `QUICK_REFERENCE.md`'s "Current Release" block still stated `^17.0.0-rc.6` for `@objectstack/spec` and `@objectstack/client` while the manifests it names as its anchors declare `^17.0.0`. Both rows now quote the anchor. The pin derives its expectation from the manifest, so the doc followed the manifest; nothing in `scripts/__tests__/quick-reference-current-release-4143.test.ts` was relaxed. 2. GA's `FieldOperatorsSchema` added `$like` and `$ilike`, which no builder operator authors, so the objectstack-ai#2942 reachability sweep reported them exactly as designed. They are excluded through that gate's own citation mechanism as "undecided — see objectstack-ai#4911" with the harvest condition written on the entry: a ruling on objectstack-ai#4911 must either delete the members and add the operators, or restate the paragraph as a decision carrying its reopen condition. No operator is implemented, no other gate logic moves, and the authoring-surface ruling stays with the maintainer. Co-authored-by: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
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