ERR_UNKNOWN_FILE_EXTENSION on Node v20.0.0

[septs]

Search Terms

Node, ERR_UNKNOWN_FILE_EXTENSION

Expected Behavior

Fix it

Actual Behavior

see Minimal reproduction

Steps to reproduce the problem

see Minimal reproduction

Minimal reproduction

$ cat example.ts
console.log('example')
$ cat tsconfig.json
{ "ts-node": { "esm": true } }
$ npx ts-node example.ts
TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for /Users/septs/Projects/example/example.ts
    at new NodeError (node:internal/errors:399:5)
    at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:99:9)
    at defaultGetFormat (node:internal/modules/esm/get_format:139:38)
    at defaultLoad (node:internal/modules/esm/load:83:20)
    at nextLoad (node:internal/modules/esm/hooks:781:28)
    at load (/Users/septs/.npm/_npx/1bf7c3c15bf47d04/node_modules/ts-node/dist/child/child-loader.js:19:122)
    at nextLoad (node:internal/modules/esm/hooks:781:28)
    at Hooks.load (node:internal/modules/esm/hooks:381:26)
    at handleMessage (node:internal/modules/esm/worker:153:24)
    at checkForMessages (node:internal/modules/esm/worker:102:28) {
  code: 'ERR_UNKNOWN_FILE_EXTENSION'
}

Specifications

• ts-node version: 10.9.1

• node version: 20.0.0

• TypeScript version: 5.0

• tsconfig.json:

  { "ts-node": { "esm": true } }

• package.json:

  {}

• Operating system and version: macOS 13.3.1

[septs]

microsoft/TypeScript#53922

---

Edited by 11/18/2023

Use tsx replace ts-node?

Or use ts-node@beta?

more see https://github.com/privatenumber/tsx, #2077

[csvn]

I have the same issue. I tried using --esm, { "esm": true } and --loader="ts-node/register", but got the ERR_UNKNOWN_FILE_EXTENSION no matter what I tried. Could not get ts-node to run on Node v20 with native ESM modules.

[Jack-Works]

FYI Node 20 has made a breaking change:

Custom ESM loader hooks run on dedicated thread
ESM hooks supplied via loaders (--experimental-loader=foo.mjs) now run in a dedicated thread, isolated from the main thread. This provides a separate scope for loaders and ensures no cross-contamination between loaders and application code.

https://nodejs.org/en/blog/release/v20.0.0

[RobinTail]

+1

The issue also appears when using the specially dedicated ESM runner

$ ts-node-esm file.ts

[manuth]

I went forward and downgraded my node version to lts.
However, doing node --loader ts-node/esm {file} did work for me.

[wibed]

i expirience the same issue on:

# node --version
v18.16.0

EDIT:
my bad, i misinterpreted the gravity of the situation. manually enforcing the loader like this.

{
  "start": "npm run clean && cross-env NODE_ENV=development NODE_OPTIONS=\"--loader=ts-node/esm --trace-warnings\" webpack serve --mode=development --config webpack.config.ts",
}

worked out.

example sourced from here:
webpack/webpack-cli#2458

[RandivCosta]

i expirience the same issue on: Node v20,
I tried: $ node --loader ts-node/esm ./path
It worked for me but getting this warnning:
ExperimentalWarning: Custom ESM Loaders is an experimental feature and might change at any time

[sywesk]

I'd like to add quickly that on windows (at least), doing node --loader ts-node/esm ./path works but with an insanely high CPU usage. Doing a quick npx tsc + node ./build/app.js works perfectly without the performance issue.

[RobinTail]

Yes, node --no-warnings=ExperimentalWarning --loader ts-node/esm file.ts helps to bypass the issue until it's fixed.

[Aenigma]

yeah, I recently upgraded to node 20 and started running with the --loader ts-node/esm parameter but noticed that my memory usage in my application had skyrocketed to 32G before it would die from OOM. I went chasing for a cause because I assumed it was due to a change I made, but downgrading to node 19 lowered memory usage down to around 500M again. I assume this is probably related to the CPU issues @sywesk had.

So I'd recommend people stay off Node 20 until this is fixed if you don't want to have unexpected issues in your runtime.

[nivethan-dev]

My solution was to use vite-node instead.

i spend hours and hours on just setting up a project and this worked on first try. all i had to do is install vite-node and execute the following script. stupid simple!

    "dev": "vite-node --watch src/index.ts",

[jonahallibone]

Is this never going to be fixed? I am still confused what the problem even is

[saillingaway]

I'm on node v 20.18.0 and encountering this issue. After reading through the entire thread it's unclear to me what the overall accepted solution to this issue is...or if there isn't one still. Can someone provide a little clarity? Thanks.

[bennycode]

I'm on node v 20.18.0 and encountering this issue. After reading through the entire thread it's unclear to me what the overall accepted solution to this issue is...or if there isn't one still. Can someone provide a little clarity? Thanks.

Does the following script work for you (it does type checking and then runs ts-node with ESM support)?

tsc --noEmit && node --no-warnings=ExperimentalWarning --loader ts-node/esm ./src/start.ts

[saillingaway]

@bennycode I saw it was a temporary fix but didn't try it because I saw a couple replies saying it ate up their CPU. Is that just the workaround at this point?

[TopchetoEU]

this issue has been open for an year and a half, and yet, seemingly, no progress has been made on it. ESM is probably the ONE thing this project should get right, and this is a CRITICAL issue. how in the livid hell does this happen.

[bisubus]

@bennycode This may require this fix nodejs/node#48207 (comment)

[septs]

seems unsolvable

---

i hope the official will open a replacement issue

[TazmanianDI]

@septs How is this unsolveable if other tools like tsx handle this just fine? This seems like a death decision for ts-node and you might as well mark it as deprecated and no longer supported.

[felipecrs]

(@septs is this issue's reporter, not a ts-node maintainer)

[phosmium]

ts-node is dead, use bun instead. Just switch, faster and easier

[TopchetoEU]

so far it seems that tsx is the go-to replacement, we should abandon this software like its creators did. also @phosmium can we stop with the shilling of alternative runtimes, because, as good as bun may be, it is just not available as an option to some of us

[bennycode]

@bisubus Great idea to pair tsc --noEmit with ts-node --transpileOnly. Since tsc already checks the types, we can run ts-node afterwards to just compile, skipping a second type check. 👍

[bisubus]

@TopchetoEU tsx isn't a full replacement and doesn't have type checks, I'm a bit sceptical about their development model privatenumber/tsx#671 . Not even accepting contributions without a donation?

[felipecrs]

I still think tsimp is a better replacement.

[shinebayar-g]

@TopchetoEU tsx isn't a full replacement and doesn't have type checks, I'm a bit sceptical about their development model privatenumber/tsx#671 . Not even accepting contributions without a donation?

lol this is gold. nodejs should stop recommending this.

[bennycode]

I still think tsimp is a better replacement.

Why do you think so? I ran into multiple issues when using it: tapjs/tsimp#26

[felipecrs]

Oh, because it typechecks using tsc. That's why.

[TopchetoEU]

@TopchetoEU tsx isn't a full replacement and doesn't have type checks, I'm a bit sceptical about their development model privatenumber/tsx#671 . Not even accepting contributions without a donation?

good point, but at least it still works with ESM.

[NoahAndrews]

tsimp is great in theory, but it's extremely buggy, and can produce non-obviously stale results from because of caching bugs. tsc --noEmit && tsx is the way for now.

[the94air]

ts-watch seems not affected with these breaking changes in node 20. I haven't tested it with bigger projects yet.