Status · evidence before labels

Is tscc production-ready?

Not yet as a general TypeScript compiler. It is now a qualified bounded Linux compiler-preview candidate with a meaningful semantic checker - still not a safe drop-in replacement for tsc.

14 September 2026 reassessment:

TSCC is materially closer to a real type-checking compiler than this page previously described. Generics/inference, overloads, classes, CFG narrowing, bounded advanced types, package/declaration/config foundations, JSX semantics, source maps, declaration output and incremental-output identity now exist in bounded form. The verdict remains not yet production-ready as a general TypeScript compiler; the remaining risk is compatibility breadth, ecosystem/project completeness and real-world evidence rather than absence of compiler architecture.

Candid verdict:

Use tscc for controlled evaluation, compiler research, and selected fast build paths where its exact syntax/module contract is known and an independent type-check remains in CI. Do not make it the sole correctness gate for an arbitrary production TypeScript application.

What is already credible

  • A real lexer/parser and range-based native emitter, not a regex-only syntax stripper.
  • Runtime-bearing transforms for enums, namespaces and parameter properties.
  • Relative multi-file discovery, project output layout and cycle de-duplication.
  • CommonJS lowering tested against observable tsc runtime behavior.
  • TSX preserve mode with dedicated ambiguity and malformed-input coverage.
  • A current 618-case external contract at 600 pass, zero fail and 18 explicit semantic skips; the frozen preview baseline remains 579 / 555 / 0 / 24 for historical comparison.
  • Canonical primitive, literal, union, callable, structural object, array and tuple types with bounded contextual and cross-module checking.
  • Explicit default emit-on-error, opt-in noEmitOnError, file-local diagnostics and staged individual output replacement.
  • A clean reproducible candidate build, ASan+UBSan, 400 mutations, frozen projects and a 7/7 Node/JS++ runtime intersection.

Why the answer is still “not yet”

A production TypeScript compiler needs much more than valid JavaScript output. tscc now has binder-owned identity, durable primitive/object/callable/array/tuple facts, contextual callbacks, index/call signatures and relative cross-module type propagation. It now has bounded inference, CFG-based narrowing, overload resolution, class semantics and hermetic standard-library foundations, but those areas remain incomplete relative to TypeScript's full relations, library ecosystem and diagnostic surface.

Its project layer now includes practical relative and bounded Node-style resolution, declaration inputs and selected JSONC path/config mapping. Project references, the wider configuration surface, full package-condition behavior and broad declaration/library ecosystems remain incomplete.

Operational gaps under active scrutiny

Output policy is now deliberate: default mode emits successfully prepared files despite other errors, while noEmitOnError commits none. Files are staged before rename, but a sequence of filesystem renames is not a transactional multi-file commit. The supported TypeScript oracle range still needs durable pinning; fuzzing, larger real-world projects, memory measurements, cross-platform validation and reproducible release packaging need deeper evidence before a broad production claim.

Two different milestones

Transpiler

A bounded syntax/module subset with correct runtime output, controlled rejection, reliable projects and production-grade operational behavior.

Checker

Durable syntax, scopes, symbols, types, inference and cross-module semantic diagnostics for a versioned compatibility contract.

Final goal

A production-ready type-checking compiler. The first milestone is useful, but it does not replace the second.

What would change this assessment?

The bounded preview now also has CP71-73 generated-project, sanitizer/RSS and strict external Valgrind evidence. External semantic coverage has now been reconciled and the first real-package probes are retained. Broader adoption still needs CP81-85 to close the highest-frequency project blockers, plus reproducible cross-platform packaging/evidence and a substantially larger compatibility contract. Read the compiler-preview contract and living roadmap.

Compiler preview finish line

The next target is not drop-in tsc compatibility. TCP0 freezes the exact supported and excluded matrix plus a multi-file positive project and negative diagnostic sibling. TCP1-TCP5 then pin diagnostics, project/output behavior, semantic closure, the JS++ runtime intersection and reproducible candidate evidence. Any implementation checkpoint must close a failed acceptance item or stay outside the preview milestone.

TCP0 complete: the manifest pins ES2022, preserve/esnext/commonjs, JSX preserve, the currently checked primitive/callable/object/array subset, emitted-only transforms and explicit exclusions including package resolution, source maps and declaration emission. Production compilation has no Node, tsc or JS++ dependency.

TCP1-TCP5 complete: diagnostics, output policy, cross-module semantic closure, the 7/7 runtime intersection and reproducible candidate evidence now qualify the bounded Linux preview. This changes the evidence level, not the explicit non-goal of drop-in tsc compatibility.