Don't crash type-aware linting when the project's tsbuildinfo doesn't exist yet#241
Merged
Conversation
Only the default `tsconfig.tsbuildinfo` name was guarded, so a project with a custom `tsBuildInfoFile` (e.g. "declarations/.tsbuildinfo") that hasn't been built yet crashed type-aware linting of every file with `Parsing error: ENOENT`. The watch program reads the buildinfo without a fileExists probe, so readFile must report missing as absent per the ts.sys contract. Also return the real content when the file does exist. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
NullVoxPopuli
commented
Jul 8, 2026
| let content = ''; | ||
| if (fileName.endsWith('tsconfig.tsbuildinfo')) { | ||
| return content; | ||
| if (fileName.endsWith('.tsbuildinfo')) { |
Member
Author
There was a problem hiding this comment.
the main fix here is that we don't require tsconfig prefix
NullVoxPopuli
commented
Jul 8, 2026
Only the default `tsconfig.tsbuildinfo` name was guarded, so a project with a custom `tsBuildInfoFile` (e.g. "declarations/.tsbuildinfo") that hasn't been built yet crashed type-aware linting of every file with `Parsing error: ENOENT`. The watch program reads the buildinfo without a fileExists probe, so readFile must report missing as absent per the ts.sys contract. Buildinfo is never a .gts/.gjs file, so instead of guarding with our own fs call, delegate to the unpatched host readFile: content when present, undefined when missing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
NullVoxPopuli
force-pushed
the
nvp/fix-tsbuildinfo-enoent
branch
from
28001d1 to
0d0c6f6
Compare
wagenet
approved these changes
Jul 8, 2026
Contributor
🏎️ Benchmark ComparisonParse
Full mitata output
Full mitata output |
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.
Running eslint with type-aware rules on a project whose tsconfig sets a custom
tsBuildInfoFile(e.g."tsBuildInfoFile": "declarations/.tsbuildinfo") blows up on a fresh checkout / after cleaning build output:...for every file in the project.
The patched
ts.sys.readFilealready guards the default buildinfo name (tsconfig.tsbuildinfo→ returns''), but any other name falls through to the gts/gjs rename fallback, matches neither, and the secondreadFileSyncthrows. The watch program (readBuilderProgram) reads the buildinfo without afileExistsprobe, soreadFilehas to report a missing file as absent (that'sts.sys.readFile's contract) rather than throw.Fix: buildinfo is never a .gts/.gjs file, so the patched readFile just delegates any
.tsbuildinfopath to the unpatched host readFile — content when present,undefinedwhen missing. (This also means an existing default-named buildinfo is now actually read instead of discarded.)Test covers both cases; the missing-file case fails on main with the exact ENOENT above.
🤖 Generated with Claude Code