AI opinion: tscc is now a real compiler preview, but full TypeScript compatibility is still a long campaign.
The project has crossed the architectural middle. TSCC now has durable syntax and expression identity, lexical binding, one program graph, canonical types, generics and inference, overload resolution, class semantics, CFG-based narrowing, richer collections, bounded advanced types, selected JSX semantics, source maps, declaration output and an incremental-output foundation. CP71-73 then put those paths through fuzzing, sanitizer/RSS and strict Valgrind validation. That is unquestionably compiler architecture. It is not yet broad tsc compatibility.
CP75 remains a clean implementation baseline and Compiler Preview remains the right product label, but the evidence-first campaign has now been completed. The current suite is 600/0/18 across 618 cases, the compatibility matrix covers 33 areas, and three real package source distributions contributed nine classified probes. Those results select CP81-85 as the next implementation campaign.
Current ratings
These are directional engineering scores, not compatibility percentages.
What changed since the previous opinion
The largest shift is semantic depth. The earlier page still described generic inference, overloads, class semantics, broad control-flow analysis, standard-library types, package resolution, source maps, declaration emit and incremental work as missing. Much of that foundation now exists in bounded form. CP43-65 added canonical export/declaration facts, practical resolution and selected tsconfig mapping, hermetic libraries, generic identity/inference, overload sets, two-sided class types and relationships, durable expression ownership, CFG narrowing/assignment facts, richer collections and bounded advanced operators.
CP66-70 then added same-unit JSX contracts, selected runtime-bearing TypeScript type facts, deterministic line source maps, bounded declaration/declaration-map emit and deterministic incremental build/output identity. CP71 hardened the expanded compiler with deterministic mutation and generated-project campaigns. CP73 exercised the real compiler under strict Valgrind across the newer paths. CP74-75 fixed the two JSX correctness defects found during that validation rather than leaving them as documented caveats.
So how close is it to being a compiler?
It already is one. The meaningful question now is how close it is to being a broadly TypeScript-compatible production compiler. On that question there is still substantial work. TypeScript compatibility has a very long tail: declaration ecosystems, standard-library depth, package conditions and configuration variants, cross-module runtime-TypeScript facts, JSX ecosystem typing, project references, diagnostics, source-map precision, semantic incremental/watch services, newer language features and real-world package combinations all interact.
The encouraging part is that these are now mostly compatibility and ecosystem problems, not “we still need a binder/type system/CFG” problems. TSCC has crossed the architectural middle even though it has not crossed the compatibility finish line.
The external regression suite needs a different interpretation now
The original 579-case 555 / 0 / 24 result remains a frozen preview baseline. The refreshed external suite now has 618 cases: 600 pass, 0 fail, 18 explicit semantic skips, with a separate 12/12 multi-file/project gate and retained 7/7 Node/JS++ runtime intersection.
The frozen 555/0/24 result is historical evidence, not the current breadth number. TRS9 adds a 33-area compatibility matrix so parse-only, emit-only, bounded semantic, externally covered and real-project-covered capabilities are not collapsed into a single pass percentage.
The memory-safety question is closed for this campaign
CP73 added a real-binary Valgrind integration workload over multi-file compilation, JSX contracts, runtime-bearing TypeScript semantics, source maps, declarations, incremental builds, diagnostics, CommonJS and repeated project lifetimes. The measured runs reported zero Valgrind errors, zero definite/indirect/possible loss, zero still-reachable bytes and no measured TSCC file-descriptor leaks. That does not prove all future compiler states safe, but it is strong retained evidence for the CP75 pause baseline.
Why this is a good place to pause
The project is not stopped in the middle of an abstraction migration. CP72 explicitly froze the current compatibility/release decision; CP73 validated the expanded compiler; CP74 and CP75 closed the correctness bugs that validation exposed. Both the compiler and regression repositories were returned source-clean. Pausing here leaves a crisp resume point instead of a half-finished feature.
When work resumes, the first job should not be “add another TypeScript feature.” It should be to reconcile evidence and choose the next campaign from measured gaps.
What should happen next
- CP81: implement high-frequency standard-library member semantics identified by real projects.
- Add independent black-box cases for semantic families already implemented since the frozen preview.
- Build a versioned compatibility-gap matrix against the pinned TypeScript 7.0.2 oracle.
- CP82-84: close flow/definite-assignment parity, practical tsconfig breadth and reduced parser/type-grammar blockers.
- Let those failures choose the next 2-3 vertical slices - likely declaration/library depth, ecosystem module/config behavior, JSX cross-file semantics, project references or semantic incremental reuse.
- Keep the CP71-73 hardening wall green while breadth grows.
- CP85: rerun the retained real projects and choose the next blockers from measured deltas.
What I would not do next
I would not chase a high regression pass percentage by adding isolated special cases. I would not rewrite the emitter merely to look more like a traditional compiler. I would not call incremental output retention an incremental compiler service. And I would not broaden “Compiler Preview” to “production-ready” until the independent semantic corpus and real projects catch up with the implementation.
Would I keep pursuing it?
Yes. The reason is stronger now than it was in August: TSCC has demonstrated that the checkpoint method can carry a native transpiler through genuine compiler architecture without collapsing under semantic state, cross-file ownership or memory pressure. The remaining road is long, but it is a road of compatibility closure rather than a bet that the foundations will eventually exist.