Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--import flag for Node.js parity #1909

Open
Thundercraft5 opened this issue Nov 6, 2022 · 4 comments
Open

--import flag for Node.js parity #1909

Thundercraft5 opened this issue Nov 6, 2022 · 4 comments

Comments

@Thundercraft5
Copy link

Thundercraft5 commented Nov 6, 2022

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.

@Thundercraft5 Thundercraft5 changed the title Node.js native --import flag --import flag for Node.js parity Nov 6, 2022
@avi12
Copy link

avi12 commented Nov 26, 2022

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

@klippx
Copy link

klippx commented Jan 10, 2024

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
Copy link

GeoffreyBooth commented May 1, 2024

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants