Instead of ts-node: tsx

Why tsx is better

• It is actively maintained and documented, while ts-node's last release is still 10.9.2.
• ESM and CommonJS both work, and an ESM file can be imported from CommonJS, without --loader flags or per-project tsconfig tweaks.
• It transforms with esbuild and skips type checking, so scripts start quickly. Type checking moves to a separate tsc --noEmit step that runs in CI or your editor.
• Watch mode is built in (tsx watch), and tsImport() lets a tool load users' TypeScript config files without enabling tsx globally.

When to keep ts-node

Keep ts-node only if you rely on it type-checking while it runs, or on emitDecoratorMetadata, which tsx cannot support because it needs type information. Frameworks such as NestJS and TypeORM use that decorator metadata.

Switching

Switching is usually a find-and-replace in your scripts and config. Run files with tsx where you ran them with ts-node, register it with node --import tsx where you used the ts-node ESM loader, and use tsx watch in place of ts-node-dev. Then add a tsc --noEmit step to CI, so that type errors still fail the build.

Watch out

A script with type errors still runs under tsx, because it never checks types, so the tsc step in CI matters. Code that calls eval directly can behave differently after the transform, and the project depends on sponsor donations for its upkeep. Node's built-in type stripping covers less than tsx does: it rejects enums, decorators and namespaces with runtime code, ignores tsconfig paths, and needs file extensions written out in every import.

Also worth a look

• Node.js type stripping Node.js runs .ts files itself by erasing type annotations, a feature marked stable since Node 24.12 and 25.2. Use it with no extra package when your code uses only erasable syntax and needs no tsconfig paths.

More newer, better JavaScript runtimes and version managers

• nvm →, use fnm