TypeStrong / ts-node

TypeScript execution and REPL for node.js
https://typestrong.org/ts-node
MIT License
12.75k stars 529 forks source link

Export `ts-node/esm-register` #2073

Open jlenon7 opened 9 months ago

jlenon7 commented 9 months ago

Register ts-node/esm loader programmatically using register fn.

See issue #2072

klippx commented 9 months ago

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

TheUnlocked commented 8 months ago

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

kkolinko commented 8 months ago

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.

ihmpavel commented 6 months ago

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

nickmccurdy commented 6 months ago

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?

jlenon7 commented 6 months ago

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

AaronNGray commented 6 months ago

For further context and alternative example see :- https://github.com/TypeStrong/ts-node/issues/2100

ElvenMonky commented 2 months ago

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

jlenon7 commented 2 months ago

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.

parimalyeole1 commented 2 months ago

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

Thank You

eduwardo commented 1 month ago

Any update on merging this pr?

albertodiazdorado commented 2 weeks ago

It would be lovely if we could get this merged

jlenon7 commented 3 days ago

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