💬 FAQ

Is ttsc a fork of TypeScript?

No. ttsc is a separate binary built on top of typescript (the official TypeScript-Go native compiler). It uses the upstream compiler and adds a plugin model around it.

How does this differ from ttypescript / ts-patch?

ttypescript and ts-patch patch the TypeScript JavaScript compiler to enable transformer plugins. They work, but they’re patches. They have to chase every TS release.

ttsc is its own compiler. Plugins run inside the binary, not as hot patches over someone else’s compiler. The plugin contract is stable across TypeScript-Go updates.

How fast is ttsc compared to tsc?

ttsc runs on the TypeScript-Go preview compiler, and @ttsc/lint adds a marginal cost (a single AST pass shared with the type-check, so no second parse) rather than the separate tsc + eslint + prettier --check stack. Speedups are measured against the legacy stack on real repositories; see the benchmark guide for per-project ratios.

Can I use ttsc with my existing tsc setup?

Yes. ttsc reads tsconfig.json, supports the same flags, and emits the same JS. Drop npx ttsc in place of npx tsc and CI will keep working. Add plugins one at a time as you adopt them.

Can I use both tsc and ttsc?

Yes, though it’s usually unnecessary. The most common case is keeping tsc for a legacy CI matrix while running ttsc locally and in newer pipelines. Both produce equivalent emit for the same tsconfig.json.

Do I have to install @ttsc/lint?

No, ttsc works without it. But the whole point of the toolchain is the pair. Without @ttsc/lint you keep eslint+prettier as separate tools and lose the “single compile pass” benefit. The recommended install is npm install -D ttsc @ttsc/lint typescript@rc.

How do I migrate from eslint + prettier?

1. Install @ttsc/lint: npm install -D @ttsc/lint.
2. Create lint.config.ts with the rules and format block you want. The format keys mirror .prettierrc. See the Setup page for a starter.
3. Run npx ttsc fix once to apply all autofixes (lint and format) across the project.
4. Commit, then delete .eslintrc.* and .prettierrc.* and the eslint / prettier devDependencies.

Most ESLint stylistic rules have direct @ttsc/lint equivalents (no-var, prefer-const, eqeqeq, etc.). Plugin-shipped ESLint rules (eslint-plugin-react-hooks, eslint-plugin-import, etc.) don’t yet have @ttsc/lint counterparts, for those, the native rule set is being built out rule by rule.

Will my existing eslint plugins work?

Not directly. @ttsc/lint is a separate engine. Third-party rule packages can ship as @ttsc/lint contributor plugins. See the @ttsc/lint deep dive for the Go API authors implement.

What about prettier’s plugin ecosystem?

The format subset of @ttsc/lint covers Prettier’s core rewrites: semis, quotes, trailing commas, print-width reflow, import ordering, and JSDoc normalization. Prettier ecosystem plugins (prettier-plugin-svelte, prettier-plugin-tailwindcss, etc.) aren’t supported; they’re Prettier-specific.

Do I need Go installed?

No. ttsc bundles its own Go toolchain and uses it to compile plugin binaries on first run. Plugin authors may want Go locally for go test and go vet. See Local Development. Consumers don’t.

Why is the first build slow?

On a fresh machine, ttsc compiles each plugin binary into a shared user-level cache the first time you run it. On a typical machine this is under 10 seconds per plugin and happens once per source-plugin content key, so separate pnpm installs can reuse the same binary. Pre-warm with npx ttsc prepare. Drop the cache with npx ttsc clean.

Does ttsx replace tsx / ts-node?

For most projects, yes. Same ergonomics, real type-check, plugins apply. See TTSC · Execute.

The one place ttsx will trip you up: when you actually wanted to run code with type errors (rare but happens, e.g., a script that probes incomplete code). Use tsx for that.

What about Deno / Bun?

• Bun: supported as a bundler integration via @ttsc/unplugin/bun. See Bundlers.
• Deno: not directly supported. Deno has its own type-check pipeline.

What’s the relationship to typia and nestia?

Both are independent projects that ship as ttsc plugins. typia produces runtime validators from your TypeScript types; nestia wraps NestJS with typia-backed controllers and SDK generation. Neither is part of ttsc, they live in their own repos and follow their own release schedules.

Does the VS Code extension work without a Marketplace install?

Yes. Run:

npx @ttsc/vscode

It installs the bundled .vsix through the code CLI. Marketplace install is still available from the Extensions view or:

code --install-extension samchon.ttsc

VS Code doesn’t show TypeScript-Go or plugin diagnostics: what’s wrong?

1. Confirm ttsc is installed in the project: npx ttsc --version.
2. Confirm the same plugin diagnostics appear in the CLI: npx ttsc --noEmit -p <selected tsconfig>.
3. Make sure the plugin config is discoverable from the selected project root or set configFile in the tsconfig plugin entry.
4. Save the file before checking plugin diagnostics or running ttsc: Fix all lint issues / ttsc: Format document. TypeScript-Go diagnostics are live; plugin diagnostics and those commands use the saved project state. Format-on-save is the exception, it formats the live editor buffer.
5. Open View → Output, pick ttsc from the dropdown, and read the server log.
6. Run ttsc: Restart language server from the command palette.
7. Set ttsc.trace.server to "verbose" in VS Code settings, then read View → Output → ttsc (trace) if the server log is empty.

Does it work in a monorepo?

Yes. Each package has its own tsconfig.json and its own lint.config.ts. ttsc reads from the directory it’s invoked in (or -p path/to/tsconfig.json). pnpm / npm / yarn workspaces all work.

For VS Code, add packages as workspace folders when each package should keep its own ttsc, typescript, and plugin config. Save files before relying on plugin diagnostics, lint fixes, or format edits.

Source maps and declaration maps?

Standard compilerOptions. Set sourceMap: true and declarationMap: true in tsconfig.json. ttsc honors them the same way tsc does.

Is the playground running my code on a server?

No. Everything runs in the browser. The editor is Monaco; a Web Worker boots playground.wasm, the same ttsc engine the CLI uses, compiled to WebAssembly. Your source never leaves the tab.

Can I publish my own plugin?

Yes. That’s the point of the protocol being public. See Plugin Development · Publishing.

Is ttsc production-ready?

It’s the build tool for typia and nestia, both of which are. It’s still v1. There are still moving parts, especially around the playground and a few rule edge cases. If you’re shipping a library, do not publish ttsc as a peer dependency yet; treat it as a build-time dependency.

Where do I report bugs?

GitHub Issues . Include ttsc --version, your Node version, your tsconfig.json, your lint.config.ts, and a minimal reproduction.

See also

• Setup: get a working ttsc install first.
• TTSC · Compile: every flag and subcommand.
• Lint & Prettier: the rule catalog and lint.config.ts reference.