fix(check): include .astro files in checked project references - #17715

Cold-start review (no prior context on this change). I verified the patch against the real @volar/kit@2.4.28 npm tarball, checked the upstream PR, the fixture/test structure, the blast radius across the monorepo, and pnpm's patch-mismatch semantics.

Verdict: request changes — one blocking design issue. The patch itself is correct and byte-identical to the upstream fix, but a patchedDependencies entry does not ship to npm consumers, so this does not actually fix astro check for users.

Blocking: the fix never reaches published packages

@astrojs/language-server builds with tsc -b (no bundling) and declares "@volar/kit": "~2.4.28" as a runtime dependency. @astrojs/check likewise builds with tsc -b and depends on @astrojs/language-server. pnpm's patchedDependencies only rewrites this monorepo's own node_modules; it is not encoded in the published tarballs and is not honoured by a consumer's npm/yarn/pnpm install. So after this lands and releases:

• the repo's own tests go green,
• the VS Code extension does get the fix (packages/language-tools/vscode/scripts/build.mjs runs esbuild with bundle: true and only externalises vscode/@astrojs/compiler/prettier*, so the patched @volar/kit is inlined),
• but everyone running astro check from npm still gets unpatched @volar/kit and still sees #17478.

That also makes the changeset inaccurate (see inline comment).

Suggested alternatives, roughly in order of preference:

1. Land volarjs/volar.js#315 upstream and bump the dep — the real fix.
2. Implement the equivalent in this repo's own source so it actually ships. createTypeScriptChecker's setup callback already receives project.typescript (configFileName + languageServiceHost), and check.ts already wraps it for addAstroTypes. Re-parsing the referenced configFileName with extraFileExtensions and augmenting getScriptFileNames there would be contained, testable, and present in the published package.
3. If a patch is kept as a stopgap, say so explicitly in the changeset and keep the issue open, because end users are not fixed.

Verified good

• Patch fidelity. The patch is byte-for-byte the same hunk as upstream volarjs/volar.js#315 (including the comment text). I confirmed that PR is still open and unmerged — single commit 4691af3c (2026-07-22), no reviews, no comments. Zero divergence from upstream is the best possible property for a patch like this.
• Correctness vs. the root-tsconfig path. In the real 2.4.28 tarball, the root config is parsed at lib/createChecker.js:16 as ts.parseJsonSourceFileConfigFileContent(ts.readJsonConfigFile(tsconfigPath, ts.sys.readFile), ts.sys, path.dirname(...), undefined, tsconfigPath, undefined, <extraFileExtensions>). The patch reproduces that call shape exactly for each reference, so ts.sys usage, discarded .errors, and argument positions are consistent with existing behaviour rather than a new inconsistency. ts and path are both in scope in that module.
• Transitive / nested references are handled. visit still recurses via ref.references?.forEach(visit), and every visited ref now re-parses its own tsconfig with extraFileExtensions, so a reference chain A -> B -> C is covered at each level. Cycles are still guarded by the pre-existing tsconfigs Set. (Pre-existing, not introduced here: the Set is seeded with asPosix(configFileName) for the root but stores raw ref.sourceFile.fileName for refs, so the normalisation is asymmetric — worth an upstream note, not a blocker.)
• No hot-path perf regression. The getCommandLine thunk is invoked once eagerly at createTypeScriptCheckerLanguageService (line 225) and thereafter only from checkRootFilesUpdate() when a watched file is created/deleted. It is not called per getScriptFileNames(), so re-parsing from disk inside it is bounded.
• Blast radius is small (item 4). @volar/kit has exactly one importer in the monorepo — packages/language-tools/language-server/src/check.ts — and one entry in pnpm-lock.yaml. No transitive consumers. One knock-on worth knowing: check.ts registers the Svelte and Vue language plugins alongside Astro, so this patch also newly pulls .vue/.svelte files out of referenced projects into the program. They are filtered out of linting at check.ts:~70, so no new diagnostics, but they will now be parsed and held in memory. That is parity with how the root tsconfig already behaves, so I read it as intended rather than a bug.
• Future-upgrade risk is safe, loud, not silent (item 8). The repo pins pnpm@11.13.1. The patch key is an exact version, and allowUnusedPatches defaults to false, so bumping @volar/kit to 2.4.29 leaves the patch unused and pnpm install fails with ERR_PNPM_PATCH_NOT_APPLIED. Separately, pnpm v11 removed ignorePatchFailures — patch application failures now always throw. And the lockfile stores the patch content hash, so --frozen-lockfile CI also catches a hand-edited patch file. There is no path where the patch silently stops applying or silently applies wrong. The residual-risk note in the PR description is accurate. Two things worth calling out anyway: this would be the repo's first patchedDependencies entry (no patches/ directory existed before), which is a new maintenance concept maintainers may not want; and because package.json declares ~2.4.28, a perfectly routine pnpm update inside the tilde range will hard-break pnpm install for every contributor until someone re-diffs the patch.

Test review (item 6)

The fixture structure genuinely exercises cross-reference checking: fixture-references/tsconfig.json is {"files": [], "references": [{"path": "./tsconfig.app.json"}]} and tsconfig.app.json is {"include": ["src"]}, so src/hasError.astro is reachable only through the project reference. The errors: 1 -> 2 assertion is the load-bearing one and cannot pass by accident. The stated verification method (removing the patch, reinstalling, watching both new assertions fail) is credible — both assertions depend solely on the referenced project's file list. See the inline comment for a weakness in the second test.

On the two "unrelated pre-existing failures" (item 7)

They are unrelated to this change — @astrojs/svelte/@astrojs/vue only affect check/fixture/frameworks/Component.{svelte,vue}, which drive the fileResult.length === 4 and fileChecked === 6 assertions in the first describe, not the project-references block.

But they are not pre-existing in a correctly installed tree: both are declared as workspace:* in test/package.json and both packages exist in this repo at packages/integrations/svelte and packages/integrations/vue. So this looks like an incomplete/filtered local install rather than a repo-level breakage, which means part of the local verification ran against a degraded environment. Please confirm the full check.test.ts suite is green in CI before merge.