Feature Request: Support type-aware code generation via plugins

[escaton]

Motivation

I've recently experimented with typia (+ nestia) in a NestJS backend project, and was impressed by how clean the developer experience is:

• No mess of decorators required for both proper runtime validations and OpenAPI generation.
• Pure TypeScript types drive both runtime validation and API metadata.
• A type-aware AoT build step produces all the necessary runtime code.

This leads to a much cleaner codebase compared to decorator-heavy approaches.

In short, this is what Typia build pipeline does:

• Patch into TypeScript compiler with ts-patch.
• Find Typia API calls in the AST (typia.assert<T>(), etc.).
• Use TypeChecker to resolve <T> into full type info.
• Generate runtime code (validators, serializers, schemas) based on that type.
• Replace call site with generated code and let tsc emit JS.

The Problem

Currently, Typia depends on the TypeScript compiler itself and ts-patch to inject its logic.

This has two limitations:

• It cannot run without hooking into TypeScript implementation, which will become impossible once ts-go becomes the reference implementation.
• It ties into compiler internals in a fragile way.

Worth noting that what is really needed from Typescript in this whole thing is: just to resolve the type info at a given place in the source.

Proposal

Typia-style AoT type-aware transformations could live directly in the SWC plugin system, instead of requiring a separate build step with additional tooling.

Benefits of doing this inside SWC:

• No extra compilation pass — avoids the build performance hit of running SWC and TypeScript sequentially.
• Pluggable & modular — logic is encapsulated in an SWC plugin, not patched into compiler internals.
• Future-proof — can adapt to ts-go (or other TS frontends) instead of being locked to current tsc.

What's possible today:
Thanks to #9132, plugins can now consume the TypeScript AST.

What's missing:
A way for plugins to access type information (via a TS/ts-go service or their own).

Open Questions

Plugin <-> Type Service communication:

WASI (wasip1) currently does not allow spawning subprocesses for IPC, so plugins cannot directly start a tsserver/LSP process.

Is there any way for a plugin to act as (or connect to) a singleton service to handle type queries across files?

Possible approaches:

Plugins manage their own TS service (preferred):

• Each plugin can choose which TypeScript version to use.
• Future-proof, since it can adapt to ts-go once available.
• Needs an API to spawn an arbitrary process and communicate with it from inside the plugin

SWC provides a standard type-service interface:

• SWC itself exposes kind of LSP-proxy to query type information.
• All plugins benefit, but this is a bigger design change.
• SWC becomes tied to Typescript implementations (current tsserver and future tsgo lsp)

I lean toward (1) because it gives plugins more flexibility, but I’d love to hear your perspective on feasibility.

Why This Matters

If this works, it would unlock a new class of type-driven AoT code generators in the SWC ecosystem — enabling projects like Typia (and others we haven’t seen yet) to run without tying themselves to current tsc internals.

[kdy1]

I'm open to maintaining it if someone implements an initial version and send a PR

[escaton]

Do you have any preferences about the implementation? Appreciate, if you can share how you see it integrated in the grand scheme of SWC.

[escaton]

@Hookyns I saw your comments in microsoft/typescript-go#455 (reply in thread) I think this could be relevant to your plans for Rttist?