Yes. Node.js can run .ts files that use only erasable syntax by stripping the types, and the docs mark this Stable. It does no type checking at all, so your strict settings protect you only if you still run the TypeScript compiler in CI.
What the Node.js docs say
The TypeScript page in the Node.js docs gives these facts:
- Type stripping is Stability 2 (Stable), from v25.2.0 and v24.12.0. It has been on by default since v23.6.0 and v22.18.0.
- Node replaces inline types with whitespace, so line numbers stay correct and no source maps are needed.
- No type checking is performed.
--no-strip-typesturns the feature off.- Node ignores
tsconfig.json. Features that depend on it, such aspaths, are intentionally unsupported. - Node refuses to process TypeScript files under a
node_modulespath.
What you lose
| You might assume | What actually happens |
|---|---|
| Strict flags apply at run time | They do not. Node ignores tsconfig |
| Type errors stop the run | A file with type errors still runs |
| All TypeScript syntax works | Syntax that needs transforming fails |
| Imports resolve like a bundler | Extensions such as .ts are mandatory |
The docs list unsupported syntax: enum declarations, runtime namespace code, parameter properties, import aliases and decorators. Type only imports need the type keyword, otherwise Node treats them as value imports and fails at run time.
Why this is a security topic
A project that moves from a build step to running .ts directly can lose its only type gate without anyone noticing. The compiler used to run in npm run build. If that step disappears, noUncheckedIndexedAccess, strictNullChecks and the rest stop being enforced anywhere.
How to keep the safety net
- Keep a type check step in CI that does not emit files, so the compiler runs on every pull request.
- Make it a required check on the main branch.
- Use the tsconfig the Node docs recommend for TypeScript 5.8 and later, which includes
erasableSyntaxOnly. That flag makes the compiler report syntax Node cannot run, so you find it before runtime.
{
"compilerOptions": {
"noEmit": true,
"target": "esnext",
"module": "nodenext",
"rewriteRelativeImportExtensions": true,
"erasableSyntaxOnly": true,
"verbatimModuleSyntax": true
}
}
- Add
"strict": trueand the other flags you rely on to the same file. - If you need
pathsor other tsconfig features at run time, a third party loader is the route the docs mention, and that adds a dependency to review.
What to tell reviewers
State clearly where type checking happens. "Node runs it, tsc checks it in CI" is a complete answer. "Node runs it" alone leaves a gap. For the compiler flags that are worth enabling, read tsconfig flags beyond strict.
Try it yourself
Open the demo to see a pull request gate block a change. A type check job should be one of the checks that can do the same.
Click through it at your own pace, or open it full screen.
Safeguard policies and gates can fail a pull request on dependency findings next to your type check. A free scan is a quick way to see the dependency side.
Quick check
Does Node read my tsconfig.json?
No. The docs say Node.js ignores tsconfig.json.
Will a file with type errors still run?
Yes, as long as its syntax is erasable. Node does not type check.
Sources
Last reviewed: 19 October 2026.
