Tooling: bun check is not a drop-in typecheck gate yet (TS 7.0.2 vs tsc-rs 7.1.0-dev, no language-service plugins) #2913

Context

While upgrading the toolchain to Bun 1.4.4, bun check was measured as a possible replacement for the tsc-rs -b typecheck gate. It is not a drop-in replacement yet.

Measurements

Same tree, bun run --cwd apps/web next typegen already run (it is required by both):

Findings

1. bun check is pinned to TypeScript 7.0.2; the gate runs 7.1.0-dev

bun -p process.versions.typescript prints 7.0.2, and bun check and typescript@7.0.2 report exactly the same error:

apps/web/app/api/upload/[...route]/multipart.ts(1094,20): error TS2769: No overload matches this call.
  ...
            Types of property 'env' are incompatible.
              Type 'unknown' is not assignable to type 'never'.

./node_modules/.bin/tsc-rs --version prints Version 7.1.0-dev, and that checker accepts the same file (0 errors). The route handler is:

app.post("/abort", abortRequestValidator, (c) => {

So why it blocks adoption is version skew: switching the gate to bun check today fails CI on an error that the current checker resolved in 7.1.

2. Language-service plugins are ignored

bun check documents "Language service plugins do not load. bun check ignores the plugins compiler option" (https://bun.com/docs/runtime/check). tsconfig.json sets compilerOptions.plugins: [{ "name": "@effect/language-service" }]:

tsc ignores these too; tsc-rs is what loads them, which is presumably why the repo uses it.

3. next typegen is still required

Without generated Next types, bun check -b reports 13 TS2304: Cannot find name 'PageProps' errors across 10 files. typegen costs 9,006 ms, so the comparable gate totals are ~14.1 s (bun check) vs ~21.2 s cold / ~13.1 s warm (tsc-rs).

Proposal

• Cache **/*.tsbuildinfo in the CI typecheck job (keyed on tsconfig files and bun.lock, with restore-keys) instead of switching checkers: measured 12.2 s → 4.1 s warm, and it keeps the Effect diagnostics.
• Revisit bun check when process.versions.typescript is at least 7.1 and there is a decision on the Effect language-service diagnostics.

Not filed upstream: bun check agrees with typescript@7.0.2, which is the version it documents (process.versions.typescript), so this is not a Bun bug. Bun's docs ask for an issue only when bun check and tsc from the matched TypeScript version disagree.