ERR_UNKNOWN_FILE_EXTENSION since Node.js 18.19.0 (works fine with 18.18.2)

[mlenkeit]

Search Terms

• ERR_UNKNOWN_FILE_EXTENSION
• Node.js 18.19.0
• Node.js 18.18.2

Expected Behavior

npx ts-node <script.ts> works on Node.js 18.19.0 just as it does with 18.18.2.

Actual Behavior

Since the upgrade to Node.js 18.19.0, the call fails with ERR_UNKNOWN_FILE_EXTENSION.

All other potentially related parameters remained unchanged (e.g. package-lock.json, ts-config.json, etc.).

We discovered this with GitHub workflow runs that run periodically (with schedule) at short intervals; only difference since things started failing is the Node.js version.

Steps to reproduce the problem

• set up Node.js 18.19.2
• set "type": "module" in package.json
• set "esm": true in tsconfig.json
• create main.ts with something like: console.log('Hello world')
• run npx ts-node main.ts

Minimal reproduction

see https://github.com/mlenkeit/ts-node-repro

there's also a GitHub workflow to run this repo against Node.js 18.19.0 and 18.18.2:
https://github.com/mlenkeit/ts-node-repro/actions/runs/7057725777

Specifications

• ts-node version: v10.9.1
• node version: v18.19.0
• TypeScript version: v5.2.2
• tsconfig.json, if you're using one:

  {
    "extends": "@tsconfig/node18/tsconfig.json",
    "ts-node": {
      "esm": true
    },
    "compilerOptions": {
      "allowSyntheticDefaultImports": true,
      "moduleResolution": "Node",
      "module": "ESNext",
      "noImplicitAny": false,
      "strictNullChecks": true,
      "sourceMap": true,
      "outDir": "./dist",
      "resolveJsonModule": false,
      "types": [
        "node"
      ]
    },
    "exclude": ["node_modules"]
  }
  

• package.json:

  {
    "name": "ts-node-repro",
    "private": true,
    "version": "1.0.0",
    "description": "",
    "main": "index.js",
    "type": "module",
    "dependencies": {
      "@tsconfig/node18": "18.2.2",
      "@types/node": "18.16.1",
      "ts-node": "10.9.1",
      "typescript": "5.2.2"
    }
  }
  

• Operating system and version: macOS Sonoma 14.1.1

[michael42]

Workaround: You can use node --loader ts-node/esm file.ts instead of ts-node --esm file.ts (which causes a ExperimentalWarning: --experimental-loader may be removed in the future). It would be great if ts-node provided an entrypoint that calls register from node:module, which seems to be Node's preferred way of registering loaders, now.

[mlenkeit]

@michael42 thanks for the suggestion. This indeed works with both Node.js 18.18.2 and 18.19.0.

I will, however, hold back with applying that change for now, as this would require changes across a dozen or so repos. We've simply pinned Node.js to 18.18.2 for now to unblock us.

I still consider this to be a bug in ts-node.

[jetwiwo]

Same issue in node v20.10.0 (current LTS)

[JonWallsten]

Workaround: You can use node --loader ts-node/esm file.ts instead of ts-node --esm file.ts (which causes a ExperimentalWarning: --experimental-loader may be removed in the future). It would be great if ts-node provided an entrypoint that calls register from node:module, which seems to be Node's preferred way of registering loaders, now.

This does not seem to work for me:
node --loader ts-node/esm -r tsconfig-paths/register ./scripts/deploy.ts

(node:129) 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)
/builds/ci-vct-dev/aws-platform-ci/aws-cdk/scripts/deploy.ts:1
import { AWS_DOMAIN } from '../shared-lib/src/environment/compile';
^^^^^^

[jetwiwo]

Workaround: You can use node --loader ts-node/esm file.ts instead of ts-node --esm file.ts (which causes a ExperimentalWarning: --experimental-loader may be removed in the future). It would be great if ts-node provided an entrypoint that calls register from node:module, which seems to be Node's preferred way of registering loaders, now.

This does not seem to work for me: node --loader ts-node/esm -r tsconfig-paths/register ./scripts/deploy.ts

(node:129) 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)
/builds/ci-vct-dev/aws-platform-ci/aws-cdk/scripts/deploy.ts:1
import { AWS_DOMAIN } from '../shared-lib/src/environment/compile';
^^^^^^

Make sure you have "type": "module" in package.json or rename the file to file.mts

[mlenkeit]

Same issue in node v20.10.0 (current LTS)

@jetwiwo right, thanks for mentioning that. FWIW, it looks like it doesn't work with Node.js 20 at all. I've added Node.js 20 versions to the repo for reproducing the problem.

https://github.com/mlenkeit/ts-node-repro/actions/runs/7125070507

[ajvincent]

See #1997 - this sounds like a duplicate of that one.

[sovietspaceship]

Any update on this? This has rendered ts-node completely unusable and not fit for purpose. The node --loader ts-node/esm file.ts and similar workarounds do not always work, and break all existing projects that now have to temporarily implement the workaround while this gets fixed.

[qiulang]

The other workaround is to use tsx instead. tsx also comes with watch mode, which is a bonus.