chore(examples): ignore the generated vite config output - #222
Merged
Conversation
examples/basic-react-app builds with `tsc -b && vite build`, and its tsconfig.node.json is a composite project whose include list is ["vite.config.ts"] -- so `tsc -b` emits vite.config.js and vite.config.d.ts on every build. Only *.tsbuildinfo was ignored, so the other two appeared as untracked after any build and were committed by accident once. That mattered because Vite resolves vite.config.js ahead of vite.config.ts. The committed copy became the config that actually took effect, so every alias had to be written twice, and the file that won was the generated one. It also explains why CI never caught the resulting breakage. A fresh checkout has no tsbuildinfo, so tsc re-emits vite.config.js from the .ts and CI gets a correct config. Locally a cached tsbuildinfo makes tsc treat the project as up to date and skip the emit, leaving the stale committed .js for Vite to prefer. Green in CI, broken on any machine that had built before. The tracked copies are already gone. This stops them coming back.
✅ Deploy Preview for openzeppelin-ui ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
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.
Correcting the premise
This started as "add an examples build to CI". On checking, the example is already built in CI —
examples/*is inpnpm-workspace.yamland the rootbuildscript ispnpm -r build, which CI runs. I verified it: a root build produces 200 log lines fromexamples/basic-react-app. So there is no CI gap to close.The real problem is different, and it is the root cause of the broken example build we hit earlier.
What is actually wrong
examples/basic-react-appbuilds withtsc -b && vite build, and itstsconfig.node.jsonis a composite project whose include list is["vite.config.ts"]. Sotsc -bemitsvite.config.jsandvite.config.d.tson every build — they are build output, not source..gitignorecovered*.tsbuildinfobut not those two. They therefore appeared as untracked files after any build, and at some point were committed by accident.That mattered because Vite resolves
vite.config.jsahead ofvite.config.ts. The committed copy became the config that actually took effect, so every alias had to be written twice, and the file that won was the generated one.Why CI never caught the breakage this caused
This is the part worth knowing, and I had it wrong before:
tsconfig.node.tsbuildinfo, sotsc -bre-emitsvite.config.jsfrom the.ts. CI silently gets a correct config and passes.tsbuildinfomakestsctreat the project as up to date and skip the emit, leaving the stale committed.jsin place for Vite to prefer.Green in CI, broken on any machine that had built before. Adding a CI build step would not have caught it — CI was already building the example and still could not see the problem.
The change
Two
.gitignorelines, plus a comment explaining the mechanism so the next person does not re-commit them:The tracked copies were already removed in #221. This stops them coming back.
Verification
tsbuildinfo, then built:✓ built in 13.61s, andtsc -bregenerated both — confirming they are genuinely build outputgit statusshows 0 untracked files underexamples/(was 2)pnpm build(what CI runs) passes and does include the example