Node.js has spent the last two years turning TypeScript into a first-class citizen. Run node app.ts and it just works — no ts-node, no build step, no tsconfig required. That story hit a real milestone this year: type stripping went stable in Node 24.12.0 and 25.2.0. But Node 26.0.0, released 5 May 2026, also removed the one escape hatch that made this workable for real-world code — the --experimental-transform-types flag is gone entirely. If your TypeScript uses an enum, a namespace, or a constructor parameter property, native node file.ts was never going to run it. Now there’s no flag left inside Node to fix that.

TL;DR: Node’s native TypeScript support only strips erasable syntax — types, interfaces, import type. Enums, namespaces with runtime code, parameter properties, and decorators all throw ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX, because handling them means generating new JavaScript, not deleting text. A flag used to paper over that (--experimental-transform-types), but Node 26.0.0 removed it as a semver-major change. If you hit this error on Node 26+, there is no built-in fix — you rewrite the syntax or bring your own transpiler.

What does ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX actually look like?

Here’s the exact output on a clean Node v22.22.2 install — the same error shows up on every version from 22.18 through the current 26.x line. Given a three-line file with a plain enum:

enum Status {
  Active,
  Inactive,
}
console.log(Status.Active);

Running it with no flags at all — this is the default behavior, not an opt-in feature:

$ node enum-test.ts
SyntaxError [ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX]: TypeScript enum is not supported in strip-only mode
    at parseTypeScript (node:internal/modules/typescript:63:40)
    at processTypeScriptCode (node:internal/modules/typescript:133:42)
    at stripTypeScriptModuleTypes (node:internal/modules/typescript:163:10)
    ...
Node.js v22.22.2

Namespaces that export a value and constructor parameter properties (constructor(public x: number)) fail with the same error code and near-identical wording — I tested both on the same install and got TypeScript namespace declaration is not supported in strip-only mode and TypeScript parameter property is not supported in strip-only mode respectively. Plain interfaces, type aliases, and ordinary type annotations run fine with zero configuration — that part genuinely works as advertised.

Why does Node accept interfaces but reject enums?

Node’s built-in TypeScript support is called type stripping, and the name is literal: it deletes type-only syntax character-for-character without generating any replacement code. An interface, a type annotation, an import type — all of that disappears with nothing put in its place, because none of it exists at runtime anyway. That’s a mechanical, low-risk transformation, which is why it shipped unflagged in Node 22.18.0 and 23.6.0, then graduated to fully stable in 24.12.0 and 25.2.0.

An enum is different — it isn’t type-only. enum Status { Active, Inactive } has to become a real JavaScript object with real property assignments at runtime. So do parameter properties (they expand into constructor body assignments) and namespaces that export values (they expand into an IIFE). That’s not erasure, it’s compilation, and Node’s strip-only mode was deliberately built to never do that — full compilation means pulling in the syntax-transform machinery the type-stripping approach was designed to avoid.

Wasn’t there a flag for exactly this?

There was. --experimental-transform-types did real compilation instead of pure stripping, and it fixed the enum and parameter-property cases — I confirmed both run cleanly with the flag on Node 22.22.2:

$ node --experimental-transform-types enum-test.ts
0
(node:1969) ExperimentalWarning: Transform Types is an experimental
feature and might change at any time
$ node --experimental-transform-types param-props-test.ts
1 2
(node:1976) ExperimentalWarning: Transform Types is an experimental
feature and might change at any time

Notice what’s missing from that list: decorators. Even with --experimental-transform-types switched on, a class decorator (@log on a method) still throws a plain SyntaxError: Invalid or unexpected token — the flag never covered them, because decorators are still a TC39 stage 3 proposal and Node has said it won’t ship a polyfill ahead of the spec landing.

That flag is now gone. Node 26.0.0 (5 May 2026) removed --experimental-transform-types as a semver-major change — it’s listed under both “Deprecations and Removals” and the semver-major commits in the release notes (commit 89f4b6cddb, PR #61803). If you’re still on Node 24 LTS, the flag may still be there for now; on 26 and later, passing it just errors as an unrecognized option.

So what do you actually do about it?

The realistic fix is usually to stop writing the syntax that requires compilation, not to find a replacement flag. Enums are the most common offender, and the standard rewrite is a const object with as const — which happens to be erasable, and pairs well with satisfies if you also want shape-checking (we covered that combination in our satisfies operator writeup):

// instead of: enum Status { Active, Inactive }
const Status = {
  Active: "active",
  Inactive: "inactive",
} as const;
type Status = (typeof Status)[keyof typeof Status];

If you genuinely need enums, namespaces, or decorators at runtime — a large existing codebase, a framework that leans on decorators — native node file.ts isn’t the tool for that file. Run it through tsx, ts-node, or a real tsc/esbuild build step instead, and reserve bare node execution for scripts and utilities that only use erasable syntax.

Checklist before you rely on native node file.ts

• Check your Node version: unflagged since 22.18.0/23.6.0, stable since 24.12.0/25.2.0, no transform-types fallback since 26.0.0.
• Grep the file for enum, namespace, and constructor parameter properties (constructor(public / private / readonly) before assuming it’ll run natively.
• Don’t count on decorators working with any Node flag — they’re TC39 stage 3, not implemented, not polyfilled.
• If a rewrite isn’t practical, use tsx/ts-node/esbuild for that file rather than chasing a flag that no longer exists on current Node.

Tested against Node v22.22.2. Ashish, 26 August 2026.