Uh oh!
There was an error while loading. Please reload this page.
chore(runner): drop the unused "@app" vite alias and empty its ratchet - #6197
Merged
Conversation
`packages/runner/vite.config.ts` declared `"@app"` pointing at `./src/app-data`. The alias had ZERO importers: a repo-wide sweep finds `@app` only in the declaration itself and in the ratchet prose below it. The documented App Data Symlink DX does not route through it. `LocalBundleLoader` (`packages/runner/src/lib/MetadataLoader.ts`) reads that directory through relative `import.meta.glob('../app-data/…')`, and README.md / runner.mdx teach `src/app-data/` as a path, never `@app`. So deleting the line changes no behaviour and breaks no documented workflow. Note what is NOT the ground here: `src/app-data/` is not a dead target. It is git-ignored (`packages/runner/.gitignore:1`) and user-supplied — absent from a fresh checkout BY DESIGN, created by any reader who follows the documented Development Workflow. The dead thing was the unused alias, not the directory it named. Same PR, as objectui#5168's shrink-only pin requires: the `KNOWN_MISSING_PACKAGE_ALIAS_TARGETS` carve-out entry goes with it. That entry was the list's only member, so the ratchet reaches empty — every package alias entry is now guarded with no exemptions. Emptying it makes both of the carve-out pin's existing expectations vacuous: each compares [] with [] and can no longer fail for any repo state. Rather than ship a pin that cannot fail, the pin now asserts emptiness itself first — which does go red if the list is re-populated — and says in-line that the two below it are knowingly vacuous at zero. Same shape objectui#4820 left on `KNOWN_MISSING_TARGETS` in this file. Part of #5380
Contributor
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
yinlianghui-tw
marked this pull request as ready for review
August 25, 2026 00:27
yinlianghui-tw
enabled auto-merge
August 25, 2026 00:28
Uh oh!
There was an error while loading. Please reload this page.
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
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#5380
Implements triage's A′ re-ruling. All gates below were run on
bbcc46e7a, the branch head.What changed, and on what ground
packages/runner/vite.config.tsdeclared"@app"pointing at./src/app-data. Two lines gone (the alias and itsDX: App Data Symlinkcomment), on the narrower ground the re-ruling measured:@appreturns three hits: the declaration itself, and two prose lines in the ratchet file describing the carve-out. Nothing imports@appor any subpath of it.LocalBundleLoaderinpackages/runner/src/lib/MetadataLoader.tsreads the directory through relativeimport.meta.glob('../app-data/app.json')and siblings.packages/runner/README.mdandcontent/docs/utilities/runner.mdxteachsrc/app-data/as a path; neither mentions the alias.So deleting the line changes no behaviour and breaks no documented workflow. Verified rather than assumed:
pnpm exec vite buildinpackages/runnerafter the deletion — 4459 modules transformed,built in 5.49s, exit 0.What is explicitly NOT the ground
src/app-data/is not a dead target. It is git-ignored (packages/runner/.gitignore:1) and user-supplied — absent from a fresh checkout by design, and created by any reader who follows the Development Workflow the README documents. The dead thing was the unused alias, not the directory it named. This distinction is the whole history of the card and the reason the earlier reasoning was retired; the code comment now carries it so the next reader cannot re-derive the wrong version.The same-PR obligation, and what an empty list does to the pins
#5168's shrink-only pin asserts each carved-out entry is still declared and still missing, so deleting the alias without touching the carve-out reddens it. Measured, not assumed — the intermediate state was run:
That entry was the list's only member, so removing it empties the ratchet. Every consumer of
KNOWN_MISSING_PACKAGE_ALIAS_TARGETSwas read:isCarvedOut, filtering the per-entry existenceit.eachdeclaredcompared with the list[]with[], cannot fail for any repo statenowResolving(entries that are carved out and now resolve)isCarvedOutis false for everything, so this is[]unconditionallyBoth of the pin's expectations become unfailable. Shipping that would be exactly the trap this file guards against elsewhere — the
toBeGreaterThanOrEqualcases at the top of the same block exist because "a zero-hit parse would make every case below vacuous".Fix, matching the shape #4820 already left on
KNOWN_MISSING_TARGETSin this same file (that ratchet reached empty in cb83cec / #5966): the pin now asserts emptiness itself first, which does bite at zero, and states in-line that the two expectations after it are knowingly vacuous rather than accidentally so. The list itself is kept, not deleted — deleting it would remove the subject of that assertion and unwireisCarvedOut, making a future re-population an ordinary edit instead of a visible one; empty is its terminal state, and re-populating it needs a card.The new assertion was ablated to prove it can fail. Re-populating the list with one probe entry, with the mutation confirmed on disk before the run (injected marker present 1, empty-list declaration present 0):
The restore leg ran from a trap and was confirmed on disk by absent-marker (probe present 0, empty-list declaration present 1) with
git statusclean.Gates
Derived from
package.jsonand.github/workflows/, not from the dispatch order. Root vitest only, exit codes captured by redirect before any pipe.vitest runon both affected test files +packages/runner/Test Files 5 passed (5),Tests 332 passed (332)pnpm lint:root(coversscripts/)28 problems (0 errors, 28 warnings), all pre-existingno-explicit-anyin untouched fileseslint .inpackages/runner20 problems (0 errors, 20 warnings), samepnpm type-check:scripts--listFilesconfirms the edited test file is in that program, so the green is not vacuouspnpm type-checkinpackages/runnerpnpm exec vite buildinpackages/runnerbuilt in 5.49spnpm check:control-bytesOK (scanned 5113 tracked text file(s))pnpm changeset:checknode scripts/check-changeset-presence.mjsNote on the runner type-check. It first failed with
TS2307: Cannot find module '@object-ui/types'and implicit-anyfallout — the unbuilt-dependency-disttrap in a fresh worktree, not this diff. Attribution was established before rerunning:tsc --listFilesshowspackages/runner/vite.config.tsis not in that program at all (tsconfig.jsonincludes onlysrc), and every erroring file is one this PR never touches. Afterturbo run build --filter=@object-ui/runner^...(14 tasks successful) the same command exits 0.No changeset. The presence gate reports it directly: "2 file(s) changed, 0 of them published source of a package the release covers ... No source of a released package changed in this range, so no changeset is owed." A build config and a pin test are not published source; nothing user-visible ships here.
Shared-surface coordination
#4820's
KNOWN_MISSING_TARGETSlives in the same file. It is not in flight — it already landed as cb83cec (#5966), and its list is already[]onmain. This PR does not touch it:git diff BASE..HEAD | grep -c KNOWN_MISSING_TARGETSreturns 0. A scan of the 40 most recently active remote branches for commits touching either of my two files since their merge-base withmainreturned nothing, so there is no union to declare.#5968 (the
fs.existsSynccheckout-state dependence class) is untouched and stays its own card. Emptying this ratchet removes the only entry that exhibited that shape, but the class is #5968's subject, not this PR's — and the code comment says so, so nobody reads the empty list as a fix for it.Generated by Claude Code