This is great, we will get rid of

(node:2649) ExperimentalWarning: `--experimental-loader` may be removed in the future; instead use `register()`:
--import 'data:text/javascript,import { register } from "node:module"; import { pathToFileURL } from "node:url"; register("ts-node/esm", pathToFileURL("./")); register("extensionless", pathToFileURL("./"));'

if we use the --import ts-node/esm instead of --loader ts-node/esm for Node 20.x projects

Make sure to add esm-register.mjs to the files list in package.json.

Regarding the proposed patch:

1. The first argument to register(): What is the point of calling pathToFileURL() on it? Why one would want to convert a relative path to a file:// URL?

   (I would understand if it were an absolute path, resulting in an absolute URL. And in that case the second argument to register() could be omitted. But why for a relative one? register() is able to resolve relative paths relative to its second argument - that is the purpose of the second argument of register().)

2. The second argument to register(): What is the meaning of "./" here? It usually means the current working directory of a process. Why not use import.meta.url - the URL of this very module?

   (In the ExperimentalWarning, cited by klippx in a comment above, pathToFileURL("./") is used because it is inline code used on the command line. There were no module file, and "./" had a meaning in that case.)

An example can be found here:
https://nodejs.org/dist/latest-v20.x/docs/api/module.html#enabling
Click "CJS <-> ESM" switch in the top-right corner to show it in ESM syntax.

Hi @jlenon7 did you have time to look at the proposed changes? Looking forward to this PR to be merged. If I can help, i would love to

This looks good and it's nearly identical to the code Node recommends when using legacy --loader, though I'd recommend @thetutlage's suggestion. Is this enough to support --import ts-node/esm or would it have to be exposed?

Sorry the delay, I've uploaded the code with the suggestions.

For further context and alternative example see :- #2100

So what's the resolution on this? Is it coming in?

So what's the resolution on this? Is it coming in?

Well, the implementation is done. We just need to wait to the core contributors to merge it or some feedback if they need more changes.

@jlenon7 Thanks for this PR.
@blakeembrey @thetutlage, Is it possible to move forward with this PR? This will help us a lot.

Thank You

Any update on merging this pr?

It would be lovely if we could get this merged

Hey @cspotcode could you take a look on this please?

npm i -D tsx
npx tsx src/index.ts

This worked for me

I agree with @programmingwithsalim . Either tsx (based on esbuild, written in go) or swc-node (based on swc, written in rust) are the standard way to directly execute TypeScript files in 2025.

Sadly, ts-node is a relic of the past.

(Additionally: we shall keep an eye on the built-in feature of Node.js to execute TypeScript files, which is also based on swc if I am not mistaken)

@albertodiazdorado, not to mention the speed benefits - which we've all heard about but I can anecdotally confirm have indeed been picked up for us too when running node --watch, node --test and when starting up in production! Very sad for ts-node, but very exciting for swc-node and TypeScript and the world! Do you have a reference to the built-in TypeScript running feature planning from Node.js? I would like to take a look. Thanks!

@davidthornton I think this link could help you to start https://nodejs.org/docs/latest-v22.x/api/typescript.html#type-stripping