Idea: a warm, shared type-aware service — reuse one resident program across repeated/parallel checks

[Faithfinder]

An idea for serving repeated and parallel type-aware checks more cheaply — possibly already on your radar, in which case feel free to point me at the existing plan.

The workload

A coding agent's loop is edit → type-check → read errors → fix → repeat, run often — type errors are the signal it corrects against. In practice that's now several agents, plus the editor and pre-commit hooks, working the same project on one machine at the same time. The traits that matter: high-frequency, parallel, and headless — no human waiting on a UI, just a tool repeatedly asking "what are the errors?"

Why the current model strains under it

Each invocation builds a cold type-aware program with its own checker pool:

• Per iteration: the whole program and checker pool are rebuilt, so a repeated loop pays cold parse/bind every cycle — slowest exactly where it runs most.
• In parallel: several callers on one machine each stand up their own program at once. tsgo's peak memory is already high and scales with --checkers (each checker re-instantiates the shared library surface — Panda/Zod/React Query/etc.; reproducible numbers: microsoft/typescript-go#4201). So one machine runs N× that cost simultaneously.

The per-checker duplication is upstream and won't change (TS team: "sharing types between checkers is not a possibility within our current design"). This is orthogonal to that: callers pay the cost N times only because N processes each build their own program.

The idea

A warm, shared type-aware service — one resident program that repeated and parallel callers query, instead of each spawning its own. That collapses N×cost toward ~1× without touching tsgo internals, and turns each repeated check into an incremental update rather than a cold rebuild.

Why this seems to fit oxlint/tsgolint

It lines up with what oxlint/tsgolint already are and where you've already gone:

• oxlint is headless with structured diagnostics — already the right shape for a tool to consume programmatically, rather than an editor-centric LSP.
• You've already folded type-checking into linting, on exactly the "don't throw away type work" principle a resident program extends across runs:

  "tsgolint now supports emitting type checking errors from TypeScript while linting. Since type-aware rules already require checking all of the types within a file, we are able to use this existing type information rather than discarding it … it is possible to skip doing a separate type-check command altogether (e.g., tsc --noEmit)." — Type-Aware Alpha

• tsgolint already owns program construction, so the warm-program lifecycle would be yours to control.
• Memory/OOM on large monorepos is already on your beta roadmap.

Sketch (one possibility, not a spec)

• A resident tsgolint service (daemon / watch-backed) holding one program warm and applying incremental updates as files change.
• A headless query endpoint that repeated/parallel callers — agents, editor tasks, pre-commit, the --type-check command — hit to get lint + type diagnostics from that one warm program.
• oxlint connecting to the service rather than launching tsgolint per run.

Happy to share the memory numbers (#4201 is fully reproducible) and the concrete parallel-run pattern behind this.

[camc314]

Hi! Thanks for opening this discussion.

I completely agree with this approach, I've had it in the back of my mind for a while, however, have not had the resources or time to start implementing it.