erasablefy

Rewrite the three TypeScript constructs that crash under Node's type stripping — enum, value namespace, and constructor parameter-properties — into equivalent erasable syntax, in place, with runtime behavior preserved.

npx erasablefy --write "src/**/*.ts"

The problem this solves

Node 24 LTS runs .ts files directly by stripping the types out. Node 26 went further and removed --experimental-transform-types (nodejs/node#61803) — the flag that used to compile enums and parameter-properties. There is no replacement and none is planned.

So the moment a module containing an enum, a value namespace, or a constructor(private x) actually executes, you get:

SyntaxError [ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX]: Enum is not supported in strip-only mode

It passes tsc. It passes install. It blows up at runtime, on the one code path that touches the construct. tsc --erasableSyntaxOnly (TS 5.8) will flag every offender, but the fix has been manual up to now. erasablefy is the fix.

Before / after

// before — throws ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX under node --strip-types
enum Dir { Up, Down, Left, Right }

class Point {
  constructor(public readonly x: number, private y = 5) {}
}

// after — plain runtime code, strips cleanly, same behavior
const Dir = {
  "Up": 0, "Down": 1, "Left": 2, "Right": 3,
  "0": "Up", "1": "Down", "2": "Left", "3": "Right",
} as const;
type Dir = 0 | 1 | 2 | 3;

class Point {
  public readonly x: number;
  private y: number;
  constructor(x: number, y = 5) {
    this.x = x;
    this.y = y;
  }
}

Note the reverse-mapping keys ("2": "Left"). Numeric enums have them at runtime, so Dir[2] === "Left" keeps working — a naive as const object would silently drop that and change behavior. erasablefy keeps it.

What it rewrites

| Construct | Rewrite | | --- | --- | | enum (string, numeric, mixed) | as const object + value-union type, with numeric reverse mapping | | value namespace | const N = (() => { ... return {...} })() — keeps non-exported locals and closures | | constructor parameter-properties | explicit field declaration + assignment in the constructor body (after super()) |

What it refuses to touch (and tells you why)

A codemod that silently changes runtime behavior is worse than a manual fix. When erasablefy can't prove a transform is safe, it leaves the code alone and reports it:

• const enum — inlined at each use site; the object form has different semantics
• enum members with computed values (A = B << 1)
• enums or namespaces that are merged across declarations
• namespaces with a nested namespace, import =, or export =

Fix those by hand, or restructure and re-run.

Usage

# preview (default glob: src/**/*.ts)
npx erasablefy "src/**/*.ts"

# apply in place
npx erasablefy --write "src/**/*.ts"

# CI gate: exit 1 if anything still needs rewriting or manual review
npx erasablefy --check "src/**/*.ts"

Run your formatter afterward — erasablefy edits the AST and doesn't try to guess your Prettier config.

GitHub Action

Gate CI so no non-erasable syntax lands on a branch you run with node --strip-types:

# .github/workflows/erasable.yml
name: erasable-check
on: [push, pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: fernforge/erasablefy@v1
        with:
          globs: "src/**/*.ts"

Programmatic API

import { transformText, transformFiles } from "erasablefy";

const { code, result } = transformText(`enum E { A, B }`);
// result.changes  -> [{ kind: "enum", name: "E", line: 1 }]
// result.skips    -> [{ kind, name, line, reason }]

Scope

This handles the deterministic, mechanical rewrites. It does not resolve path aliases, emit decorator metadata, or bundle — if you rely on those you still need a build step (tsc, tsx, esbuild). It's aimed at the code that is otherwise ready to run on native type stripping and only trips on these three constructs.

License

MIT

Built autonomously by an AI agent.