`--import` flag for Node.js parity

[Thundercraft5]

Desired Behavior

Should work exactly as node's --import flag, optionally an -I alias.

Alternatives you've considered

Running node --loader ts-node/esm with a local file path results in an error:

> node --import ".\src\configs.ts" --loader ts-node/esm
(node:9468) ExperimentalWarning: Custom ESM Loaders is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
<omitted>\Development\Libraries\NodeJS\eslint-plugin\node_modules\ts-node\dist-raw\node-internal-modules-esm-resolve.js:695
    throw new ERR_INVALID_MODULE_SPECIFIER(
          ^
CustomError: ERR_INVALID_MODULE_SPECIFIER .\src\configs.ts is not a valid package name <omitted>\Development\Libraries\NodeJS\eslint-plu
gin\
    at parsePackageName (<omitted>\Development\Libraries\NodeJS\eslint-plugin\node_modules\ts-node\dist-raw\node-internal-modules-esm-re
solve.js:695:11)
    at packageResolve (<omitted>\Development\Libraries\NodeJS\eslint-plugin\node_modules\ts-node\dist-raw\node-internal-modules-esm-reso
lve.js:713:5)
    at moduleResolve (<omitted>\Development\Libraries\NodeJS\eslint-plugin\node_modules\ts-node\dist-raw\node-internal-modules-esm-resol
ve.js:798:18)
    at Object.defaultResolve (<omitted>\Development\Libraries\NodeJS\eslint-plugin\node_modules\ts-node\dist-raw\node-internal-modules-e
sm-resolve.js:912:11)
    at <omitted>\Development\Libraries\NodeJS\eslint-plugin\node_modules\ts-node\src\esm.ts:218:35
    at entrypointFallback (<omitted>\Development\Libraries\NodeJS\eslint-plugin\node_modules\ts-node\src\esm.ts:168:34)
    at <omitted>\Development\Libraries\NodeJS\eslint-plugin\node_modules\ts-node\src\esm.ts:217:14
    at addShortCircuitFlag (<omitted>\Development\Libraries\NodeJS\eslint-plugin\node_modules\ts-node\src\esm.ts:409:21)
    at resolve (<omitted>\Development\Libraries\NodeJS\eslint-plugin\node_modules\ts-node\src\esm.ts:197:12)
    at nextResolve (node:internal/modules/esm/loader:161:28)

Additional context

Node.js recently added the --import flag in v19.

[avi12]

I'm facing the same issue as I'm trying to debug TypeScript

[klippx]

Need to bump this, it is quite annoying to see these lines

(node:50692) 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("./"));'
(Use `node --trace-warnings ...` to show where the warning was created)

Shouldn't be that hard to convert to an import flag and expose that.

[GeoffreyBooth]

Hi, I work on Node.js. The --loader flag is undocumented and there’s a good chance it will be removed in the future (along with --experimental-loader). For a few years now we’ve been encouraging people to migrate to --import.

To do so, you could create a new export from your package that calls node:module‘s register. You could create it as a CommonJS file so that it would work with either --import or --require, along these lines:

const { register } = require('node:module');
const { pathToFileURL } = require('node:url');
register('./esm.mjs', pathToFileURL('./'));

This file could also register the CommonJS hooks if you want to cover everything; and then your README wouldn’t need separate instructions for CommonJS and ESM.

If you create this and update your README accordingly, you will be future-proofing your package and removing reliance on Node experimental flags.

[albertodiazdorado]

Are there any reason why this should not be implemented?

ts-node is on the not-usable side of things if it forces us into deprecated Nodejs flags.

[sliekens]

I understand time is scarce and maintainers are doing their best, but setting up ts-node is a bad experience right now, compared to setting up tsx.

1. Users are instructed to use the deprecated --loader option by documentation
2. This prints an ExperimentalWarning, for something that the user cannot fix
3. Trying to use --import doesn't work at all, not even a warning that it is not supported

Wheras node --import tsx just works without any sweat.

[albertodiazdorado]

Yes @sliekens , I believe that ts-node is pretty much a dead project at this point. tsx or even @swc/node should be preferred.