Development

JS++ and tscc.

The projects reinforce one another without becoming one codebase. tscc is a TypeScript compiler. JS++ is an embeddable JavaScript runtime.

CP1 complete: this ownership and dependency boundary is now a settled repository contract. Normal tscc compilation remains independent of JS++.
tscc CP3 complete: tscc now retains a durable per-file compilation unit through emission. This changes no ownership here: no compiler component has migrated to JS++, and integration remains test-only first.
tscc CP4 complete: one production program graph now owns roots, files, dependency edges and durable units. JS++ remains outside normal compilation.
tscc CP5 complete: structural syntax now has durable identity and recovery nodes. This remains compiler-owned TypeScript structure, not a component migration.
tscc CP8 complete: recovery now retains following declarations and offers a deterministic parser work ceiling. The parser remains TSCC-owned; no syntax code has migrated into JS++.
CP9/INT0 complete: six eligible tscc outputs now execute independently under Node and JS++, with explicit expected values and anti-agreement checks. This remains opt-in test infrastructure.

JS++

  • executable ECMAScript syntax
  • bytecode and runtime execution
  • values, objects and prototypes
  • closures, exceptions and GC
  • jobs, modules and embedding

tscc

  • TypeScript syntax and recovery
  • symbols, types and checking
  • compiler diagnostics
  • project and module resolution
  • lowering and JavaScript emission

First integration: tests

TypeScript source
      ↓
     tscc
      ↓
JavaScript output
   ↙       ↘
 Node      JS++
oracle   candidate runtime

Node remains the initial compatibility oracle. The first six-case intersection now runs through both public CLIs and explicit expected values; JS++ failures remain separately classified engine gaps rather than silently becoming normal tscc regressions.

Nothing migrates initially

Existing componentInitial ownership
TypeScript lexer and parsertscc
Range erasure and replacementstscc during migration
Binder and checkertscc
CommonJS loweringtscc
JavaScript runtime harnessGeneralized for Node and JS++
ECMAScript runtime semanticsJS++

Later decision gates

Once both parsers exist, compare tokens, diagnostics, losslessness, recovery and TypeScript extension needs. Share only a small public syntax facility if evidence proves it serves both products. Private cross-repository includes are not acceptable architecture.

Optional JS++ embedding in tscc is considered only for a concrete bounded feature such as plugin execution or deterministic configuration. Normal compilation never executes user source as a shortcut around type checking.

Default trajectory: test-only integration first, optional embedding later, and no required runtime dependency without strong evidence and an explicit product decision.