Ecosystem Map

This page maps the active repositories, packages, and ownership boundaries in the current Tsonic stack.

Compiler and user entrypoint

tsonic

tsonic owns:

• parsing, typing, validation, IR, emission, backend orchestration
• the CLI commands users run
• the workspace, project, and package model
• the compiler quality bar (./test/scripts/run-all.sh)

Public docs: /tsonic/

Authoring packages

@tsonic/core

Language-facing types and intrinsics:

• numeric branded types such as int, long, byte, double
• lang.js helpers such as nameof, sizeof, defaultof, out, stackalloc, asinterface, and trycast

@tsonic/globals

Shared ambient declarations used by surface and package layers.

These two packages are foundational, but they are not “ambient worlds” on their own. They support the compiler and the higher-level package model.

First-party TypeScript source packages

These are the public authored packages in the current stack.

@tsonic/js

Role:

• active JavaScript ambient surface
• first-party tsonic-source-package
• canonical source for JS-style globals and receiver methods

Examples of what it provides:

• console
• JSON
• Date
• Map, Set
• typed arrays
• timers

Public docs: /js/

@tsonic/nodejs

Role:

• first-party source package for Node-style modules
• layered on top of @tsonic/js
• package metadata declares node:* aliases and runtime requirements

Examples of what it provides:

• node:fs
• node:path
• node:http
• node:crypto
• node:stream
• node:net
• node:tls

Public docs: /nodejs/

@tsonic/express

Role:

• first-party source package for Express-style routing and middleware
• canonical package for the Express layer
• authored in TypeScript and consumed as source

Public docs: /express/

Generated CLR binding packages

These packages are generated by tsbindgen from CLR metadata.

Core families

• @tsonic/dotnet
• @tsonic/aspnetcore
• @tsonic/microsoft-extensions
• @tsonic/efcore
• @tsonic/efcore-sqlite
• @tsonic/efcore-sqlserver
• @tsonic/efcore-npgsql

These are not authored source packages in the same sense as js, nodejs, and express.

They exist to project CLR namespaces, members, overloads, extension methods, and metadata into TypeScript packages that Tsonic can consume.

Public docs: /tsbindgen/

Repo ownership model

Repo / package family	Owns	Validation bar
tsonic	compiler + CLI + project model	full run-all
js	JS surface and authored source package	package selftest + downstreams
nodejs	Node-style source package	package selftest + downstreams
express	Express-style source package	package selftest + downstreams
tsbindgen	generated CLR binding pipeline	generator tests + wave preflight
dotnet / aspnetcore / microsoft-extensions / efcore*	generated CLR binding packages	regen + downstream verification
proof-is-in-the-pudding, tsumo, clickmeter, Jotster	ecosystem consumers	downstream verification

Downstream verification repos

These repos are part of the real quality bar, not just demos:

• proof-is-in-the-pudding
• tsumo
• clickmeter
• Jotster

They matter because they exercise:

• real package graphs
• real generated projects
• runtime startup and request handling
• end-to-end integration with generated bindings

Current public mental model

Going forward, the correct explanation is:

• authored public packages are first-party TypeScript source packages
• CLR-facing packages are generated by tsbindgen
• the ecosystem is released as a verified wave, not as isolated repo islands