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.

[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.

[bennycode]

I created a video summarizing how to run ts-node with ESM on Node 20+: https://www.youtube.com/watch?v=-7dNs1ggKRs

The tsx tool is the recommended alternative (mentioned by @blakeembrey in #2140).

[imawizrd]

Showcase of the problem:

demo.mp4

Here's all the loaders webpack supports

[webpack-cli] Unable load '/repo/folder/webpack.config.ts'
[webpack-clil Unable to use specified module loaders for " .ts".
[webpack-clil Cannot find module 'ts-node/register' from '/repo/folder'
[webpack-cli] Cannot find module 'sucrase/register/ts' from '/repo/folder'
[webpack-clil Cannot find module '@babel/register' from '/repo/folder'
[webpack-cli] Cannot find module 'esbuild-register/dist/node' from /repo/folder'
[webpack-clil Cannot find module '@swc/register' from '/repo/folder'
[webpack-clil Please install one of them

Webpack will check them in that order, mind you. So even if you have sucrase installed for example you have to manually uninstall ts-node before webpack automatically picks sucrase as loader.

So I just did (I use Yarn package manager, if you use NPM translate these commands to their equivalent)

yarn remove ts-node

and then

yarn add -D sucrase

No more configuration is needed (I don't have "type": "module" option in package.json, if you have it you may need additional configuration) and I can run webpack --config ./webpack.config.ts without any flags or workarounds.

Another thing, if you do not have "type": "module" option in package.json, the Webpack loader compiles the typescript config to commonJS, so you must use __dirname and __filename instead of import.meta.url if you need it, but you probably already know that.

ts-node is a great project and it has served me well over the years, so I'm sorry to have to remove it from my project. Please give all the support you can give to ts-node if you value it as I do.

[wes992]

I created a video summarizing how to run ts-node with ESM on Node 20+: https://www.youtube.com/watch?v=-7dNs1ggKRs

The tsx tool is the recommended alternative (mentioned by @blakeembrey in #2140).

This worked for me. By far the best solution I have come across. :)

[felipecrs]

Well, if there's anything positive out of it, I hope it somehow incentivize people to try a better runtime like Deno or Bun.

[TopchetoEU]

Well, if there's anything positive out of it, I hope it somehow incentivize people to try a better runtime like Deno or Bun.

unfortunately, sometimes you don't get to pick your runtime, and you're forced to use NodeJS, despite your best wishes.

[dandv]

I've switched to Deno, but there are still some rough edges, especially when it comes to testing:

1. There are no IDEs with full test support. Neither WebStorm nor the VS Code Deno plugin support BDD tests.
2. expect toMatchObject does not do a diff between the objects to show the mismatched keys (Jest does, but it comes with its own TypeScript problems)

Also, there's no interop with ESLint rules, and Deno's built-in linting is just not up to par with typescript-eslint.

[shinebayar-g]

Deno is still buggy... Bun too... Those nasty bugs are so annoying to find out later in the production..
Ironically with native ESM support in NodeJS, ts-node may start work again lol.