@ttsc/lint - I made 20x faster TS Lint by building it into typescript-go — one compile catches both

TL;DR

• A typical TypeScript project runs tsc for type checking, then runs eslint again for code style.


• 
  @ttsc/lint collapses those two steps into a single compile pass. Lint violations come out as plain compile errors.


• It's built on typescript-go (the next-generation TS compiler rewritten in Go, about 10x faster than legacy tsc), and reuses the AST the compiler already builds — so there is no extra parsing cost.


• Combine "two steps into one" with "JavaScript moved to Go," and you get about 20x faster, in theory.


• 
  Compatible with TypeScript v6 — drop on top with ttsx or ttsc --noEmit, no migration.

GitHub Repository:

1. The thing every TypeScript developer does twice a day

If you've ever set up a TypeScript project, this pair of commands will look familiar.

# Are the types correct?

tsc --noEmit



# Is the code style okay?

eslint "src/**/*.ts"

CI runs them separately. Build scripts run them separately. It's a little odd when you stop and think about it: these two tools are basically doing half of the same job each.

• 
  tsc: read the source → parse it into an AST → look at types.


• 
  eslint: read the source → parse it into an AST → look at patterns.

Same source, read twice. Parsed twice. And both have to pass before your build can move on.

What if you could do it in one pass?

2. What @ttsc/lint looks like in practice

Say you wrote this file.

var x: number = 3;

let y: number = 4;

const z: string = 5;



console.log(x + y + z);

There are three problems here.

1. 
   var — usually caught by the no-var lint rule.


2. 
   let y is never reassigned — caught by prefer-const.


3. Assigning the number 5 to a string — that's an actual type error.

If you only run tsc, only #3 trips. You need a separate ESLint pass to catch #1 and #2.

Run ttsc with @ttsc/lint enabled, and the output looks like this:

$ pnpm ttsc

src/lint.ts:3:7 - error TS2322: Type 'number' is not assignable to type 'string'.



3 const z: string = 5;

        ~



src/lint.ts:2:5 - error TS17397: [prefer-const] Use const instead of let.



2 let y: number = 4;

      ~~~~~~~~~~~~~



src/lint.ts:1:1 - error TS11966: [no-var] Unexpected var, use let or const instead.



1 var x: number = 3;

  ~~~~~~~~~~~~~~~~~~



Found 3 errors in the same file, starting at: src/lint.ts:3

All three diagnostics come out together, in one compile output.

Notice that the lint violations are reported in error TSxxxxx format — exactly the same shape as a real type error. As far as the compiler is concerned, lint violations and type errors are the same kind of compile error. The exit code is non-zero, and CI that simply runs the equivalent of tsc will now block on lint violations too — no extra wiring required.

Severities are "error", "warning", or "off". Rules set to "warning" are reported but don't change the exit code, which makes gradual rollout easy.

3. So what is ttsc?

is a library that generates validation functions from TypeScript types.

Imagine you write this:

import typia, { tags } from "typia";

import { v4 } from "uuid";



const matched: boolean = typia.is<IMember>({

  id: v4(),

  email: "[email protected]",

  age: 30,

});

console.log(matched); // true



interface IMember {

  id: string & tags.Format<"uuid">;

  email: string & tags.Format<"email">;

  age: number &

    tags.Type<"uint32"> &

    tags.ExclusiveMinimum<19> &

    tags.Maximum<100>;

}

typia.is<IMember>(...) checks whether the input matches IMember. A normal library couldn't do this from a TypeScript type alone — IMember is a TypeScript type, and at runtime it doesn't exist.

typia is a transformer. At compile time, it expands the IMember type, builds the validation code that matches that exact type, and replaces the typia.is<IMember>(...) call with that code. So the compile output looks like this:

import typia from "typia";

import * as __typia_transform__isFormatEmail from "typia/lib/internal/_isFormatEmail";

import * as __typia_transform__isFormatUuid from "typia/lib/internal/_isFormatUuid";

import * as __typia_transform__isTypeUint32 from "typia/lib/internal/_isTypeUint32";

import { v4 } from "uuid";



const matched = (() => {

  const _io0 = (input) =>

    "string" === typeof input.id &&

    __typia_transform__isFormatUuid._isFormatUuid(input.id) &&

    "string" === typeof input.email &&

    __typia_transform__isFormatEmail._isFormatEmail(input.email) &&

    "number" === typeof input.age &&

    __typia_transform__isTypeUint32._isTypeUint32(input.age) &&

    19 < input.age &&

    input.age <= 100;

  return (input) => "object" === typeof input && null !== input && _io0(input);

})()({

  id: v4(),

  email: "[email protected]",

  age: 30,

});

console.log(matched);

What started as a generic-looking call has been replaced, at compile time, with validation logic specialized to IMember. The user only wrote typia.is<IMember>(...), but the output has bespoke checking code baked in.

That's a transformer. @ttsc/lint plugs into the same slot — it's just a transformer that reports violations as diagnostics instead of rewriting code.

ttsc is the compiler that standardizes and exposes this transformer slot, which is why tools like @ttsc/lint can be wired in at all.

The same plugin configuration applies to both ttsc and ttsx. A transformer that runs at build time runs the same way when you execute the file directly with ttsx.

7. Wrapping up

Bringing it back to the start:

• In a TypeScript project, you usually use tsc for types and eslint for style.


• 
  @ttsc/lint pulls lint rules into the compiler so one compile catches both.


• This works because @ttsc/lint reuses the AST typescript-go already built. No double parsing.


• And because it runs in Go instead of JavaScript, two-into-one × JS-to-Go = about 20x faster, in theory (formal benchmarks coming with TS v7).


• The thing that makes all of this possible is ttsc's transformer plugin system. Tools like typia and @ttsc/lint — anything that wants to use compile-time type information — plug into the same slot.

If you want to try it, it's three steps.

1. Install:

npm i -D ttsc @typescript/native-preview @ttsc/lint

2. Add the plugin entry to your tsconfig.json under compilerOptions.plugins (turn on whichever rules you want — they're all off by default):

{

  "compilerOptions": {

    "plugins": [

      {

        "transform": "@ttsc/lint",

        "config": {

          "no-var": "error",

          "prefer-const": "error",

          "no-explicit-any": "warning"

        }

      }

    ]

  }

}

3. Run it like you always have:

npx ttsc

That's the whole setup. Type errors and lint violations show up together, in one go.

💡 You don't have to wait for TypeScript v7 to use this. @typescript/native-preview is a side-by-side package — install it next to your existing TypeScript v6 toolchain and your current tsc build keeps working untouched. Drop ttsc on top and pick whichever overlay fits:

• Run files with ttsx instead of ts-node/tsx (tsx-class speed, with type checking).


• Run ttsc --noEmit in CI or pre-commit to get the type-check + lint pass — about 10x faster than legacy tsc, no build artifacts touched.

No migration, no commitment. Try the overlay today, keep your existing pipeline.

Repo links one more time — . ⭐ welcome.