There are two ways to enable runtime TypeScript support in Node.js:
\nFor full support of all of TypeScript's syntax and features, including\nusing any version of TypeScript, use a third-party package.
\nFor lightweight support, you can use the built-in support for\ntype stripping.
\nTo use TypeScript with full support for all TypeScript features, including\ntsconfig.json, you can use a third-party package. These instructions use\ntsx as an example but there are many other similar libraries available.
Install the package as a development dependency using whatever package\nmanager you're using for your project. For example, with npm:
npm install --save-dev tsx\nThen you can run your TypeScript code via:
\nnpx tsx your-file.ts\nOr alternatively, you can run with node via:
node --import=tsx your-file.ts\nThe flag --no-experimental-strip-types prevents Node.js from running TypeScript\nfiles. By default Node.js will execute only files that contain no\nTypeScript features that require transformation, such as enums or namespaces.\nNode.js will replace inline type annotations with whitespace,\nand no type checking is performed.\nTo enable the transformation of such features\nuse the flag --experimental-transform-types.\nTypeScript features that depend on settings within tsconfig.json,\nsuch as paths or converting newer JavaScript syntax to older standards, are\nintentionally unsupported. To get full TypeScript support, see Full TypeScript support.
The type stripping feature is designed to be lightweight.\nBy intentionally not supporting syntaxes that require JavaScript code\ngeneration, and by replacing inline types with whitespace, Node.js can run\nTypeScript code without the need for source maps.
\nType stripping works with most versions of TypeScript\nbut we recommend version 5.7 or newer with the following tsconfig.json settings:
{\n \"compilerOptions\": {\n \"target\": \"esnext\",\n \"module\": \"nodenext\",\n \"allowImportingTsExtensions\": true,\n \"rewriteRelativeImportExtensions\": true,\n \"verbatimModuleSyntax\": true\n }\n}\nNode.js supports both CommonJS and ES Modules syntax in TypeScript\nfiles. Node.js will not convert from one module system to another; if you want\nyour code to run as an ES module, you must use import and export syntax, and\nif you want your code to run as CommonJS you must use require and\nmodule.exports.
.ts files will have their module system determined the same way as .js\nfiles. To use import and export syntax, add \"type\": \"module\" to the\nnearest parent package.json..mts files will always be run as ES modules, similar to .mjs files..cts files will always be run as CommonJS modules, similar to .cjs files..tsx files are unsupported.As in JavaScript files, file extensions are mandatory in import statements\nand import() expressions: import './file.ts', not import './file'. Because\nof backward compatibility, file extensions are also mandatory in require()\ncalls: require('./file.ts'), not require('./file'), similar to how the\n.cjs extension is mandatory in require calls in CommonJS files.
The tsconfig.json option allowImportingTsExtensions will allow the\nTypeScript compiler tsc to type-check files with import specifiers that\ninclude the .ts extension.
Since Node.js is only removing inline types, any TypeScript features that\ninvolve replacing TypeScript syntax with new JavaScript syntax will error,\nunless the flag --experimental-transform-types is passed.
The most prominent features that require transformation are:
\nEnumnamespaceslegacy moduleSince Decorators are currently a TC39 Stage 3 proposal\nand will soon be supported by the JavaScript engine,\nthey are not transformed and will result in a parser error.\nThis is a temporary limitation and will be resolved in the future.
\nIn addition, Node.js does not read tsconfig.json files and does not support\nfeatures that depend on settings within tsconfig.json, such as paths or\nconverting newer JavaScript syntax into older standards.
Due to the nature of type stripping, the type keyword is necessary to\ncorrectly strip type imports. Without the type keyword, Node.js will treat the\nimport as a value import, which will result in a runtime error. The tsconfig\noption verbatimModuleSyntax can be used to match this behavior.
This example will work correctly:
\nimport type { Type1, Type2 } from './module.ts';\nimport { fn, type FnParams } from './fn.ts';\nThis will result in a runtime error:
\nimport { Type1, Type2 } from './module.ts';\nimport { fn, FnParams } from './fn.ts';\nType stripping can be enabled for --eval and STDIN. The module system\nwill be determined by --input-type, as it is for JavaScript.
TypeScript syntax is unsupported in the REPL, --check, and\ninspect.
Since inline types are replaced by whitespace, source maps are unnecessary for\ncorrect line numbers in stack traces; and Node.js does not generate them.\nWhen --experimental-transform-types is enabled, source-maps\nare enabled by default.
To discourage package authors from publishing packages written in TypeScript,\nNode.js will by default refuse to handle TypeScript files inside folders under\na node_modules path.
tsconfig \"paths\" won't be transformed and therefore produce an error. The closest\nfeature available is subpath imports with the limitation that they need to start\nwith #.