<div id="readability-page-1" class="page"><div id="page-content" data-internal-nav="false" data-current-page="stories-show">
 

 <main id="main-content">
 <div>


 <article id="article-show-container" data-article-id="3157876" data-article-slug="nodejs-worker-thread-with-typescript-5b00" data-author-id="201866" data-author-name="Composite" data-author-username="composite" data-co-author-ids="" data-path="/composite/nodejs-worker-thread-with-typescript-5b00" data-pin-path="/stories/feed/pinned_article" data-pinned-article-id="" data-published="true" data-scheduled="false" lang="en">
 
 <header id="main-title">

 
 </header>

 <div data-article-id="3157876" id="article-body">
 Have you encountered this frustrating error since updating to Node.js 20? 


<div>
<pre><code>TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for src/App.ts

</code></pre>
<div>

 <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewBox="0 0 24 24"><title>Enter fullscreen mode</title>
 <path d="M16 3h6v6h-2V5h-4V3zM2 3h6v2H4v4H2V3zm18 16v-4h2v6h-6v-2h4zM4 19h4v2H2v-6h2v4z"></path>
</svg>

 <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewBox="0 0 24 24"><title>Exit fullscreen mode</title>
 <path d="M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z"></path>
</svg>


</div>
</div>



This isn't just a minor glitch; it’s a long-standing issue in the ecosystem. You can see the ongoing discussion here:

<ul>
<li><a href="https://github.com/TypeStrong/ts-node/issues/2100" target="_blank" rel="noopener noreferrer">TypeStrong/ts-node#2100</a></li>
</ul>

The problem is especially painful when trying to run <code>.ts</code> files using <code>Worker</code>. No matter what you try, that error often greets you. Even tools like <code>ts-worker</code> from Bree don't fully support ESM yet, leaving many of us in a tough spot.

But there is a way out! If you are using Vite in your environment, the solution is closer than you think. The Vite team provides <a href="https://github.com/antfu-collective/vite-node" target="_blank" rel="noopener noreferrer">vite-node</a>, which allows you to run scripts within your Vite environment.


<hr>

<h2>
 <a name="the-solution-using-vitenode" href="#the-solution-using-vitenode">
 </a>
 The Solution: Using vite-node
</h2>

One tricky part remains: Node.js <code>Worker</code> still primarily expects <code>.js</code> or <code>.mjs</code> extensions. To bridge this gap, we'll use a small wrapper strategy.

Here’s our setup:

<ol>
<li><code>vite-node</code></li>
<li>A <code>worker_wrapper.mjs</code> file</li>
<li>
<code>parent.ts</code> and <code>child.ts</code>
</li>
</ol>

It sounds a bit complex, but it's actually quite simple once you see the code.

<h3>
 <a name="1-raw-workerwrappermjs-endraw-" href="#1-raw-workerwrappermjs-endraw-">
 </a>
 1. <code>worker_wrapper.mjs</code>
</h3>

This file uses the <code>vite-node</code> programmatic API to load and execute our TypeScript worker. 


<div>
<pre><code>import { workerData } from 'node:worker_threads';
import { createServer } from 'vite';
import { ViteNodeRunner } from 'vite-node/client';
import { ViteNodeServer } from 'vite-node/server';
import { installSourcemapsSupport } from 'vite-node/source-map';

// create vite server
const server = await createServer({
 optimizeDeps: {
 // It's recommended to disable deps optimization
 noDiscovery: true,
 include: undefined,
 },
});

// create vite-node server
const node = new ViteNodeServer(server);

// fixes stacktraces in Errors
installSourcemapsSupport({
 getSourceMap: (source) =&gt; node.getSourceMap(source),
});

// create vite-node runner
const runner = new ViteNodeRunner({
 root: server.config.root,
 base: server.config.base,
 // when having the server and runner in a different context,
 // you will need to handle the communication between them
 // and pass to this function
 fetchModule(id) {
 return node.fetchModule(id);
 },
 resolveId(id, importer) {
 return node.resolveId(id, importer);
 },
});

// execute the file
await runner.executeFile(workerData.jobpath);

// close the vite server
await server.close();

</code></pre>
<div>

 <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewBox="0 0 24 24"><title>Enter fullscreen mode</title>
 <path d="M16 3h6v6h-2V5h-4V3zM2 3h6v2H4v4H2V3zm18 16v-4h2v6h-6v-2h4zM4 19h4v2H2v-6h2v4z"></path>
</svg>

 <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewBox="0 0 24 24"><title>Exit fullscreen mode</title>
 <path d="M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z"></path>
</svg>


</div>
</div>



<h3>
 <a name="2-raw-parentts-endraw-" href="#2-raw-parentts-endraw-">
 </a>
 2. <code>parent.ts</code>
</h3>

When initializing the <code>Worker</code> instance, we point it to <code>worker_wrapper.mjs</code> instead of the <code>.ts</code> file directly. We pass the actual target path via <code>workerData</code>. 


<div>
<pre><code>import { Worker } from 'node:worker_threads';
import path from 'node:path';
// in Vite, you should declare __dirname yourself.
const worker = new Worker('./worker_wrapper.mjs', {
 workerData: {
 scriptPath: path.resolve(__dirname, './child.ts'),
 },
});

worker.on('message', (msg) =&gt; console.log('From Worker:', msg));
</code></pre>
<div>

 <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewBox="0 0 24 24"><title>Enter fullscreen mode</title>
 <path d="M16 3h6v6h-2V5h-4V3zM2 3h6v2H4v4H2V3zm18 16v-4h2v6h-6v-2h4zM4 19h4v2H2v-6h2v4z"></path>
</svg>

 <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewBox="0 0 24 24"><title>Exit fullscreen mode</title>
 <path d="M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z"></path>
</svg>


</div>
</div>



<h3>
 <a name="3-raw-childts-endraw-" href="#3-raw-childts-endraw-">
 </a>
 3. <code>child.ts</code>
</h3>

This is where your actual worker logic lives. You can write pure TypeScript here! 


<div>
<pre><code>import { parentPort } from 'node:worker_threads';

const heavyTask = (): string =&gt; {
 return "Task Completed in TypeScript!";
};

parentPort?.postMessage(heavyTask());
</code></pre>
<div>

 <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewBox="0 0 24 24"><title>Enter fullscreen mode</title>
 <path d="M16 3h6v6h-2V5h-4V3zM2 3h6v2H4v4H2V3zm18 16v-4h2v6h-6v-2h4zM4 19h4v2H2v-6h2v4z"></path>
</svg>

 <svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewBox="0 0 24 24"><title>Exit fullscreen mode</title>
 <path d="M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z"></path>
</svg>


</div>
</div>




<hr>

<h2>
 <a name="why-this-works" href="#why-this-works">
 </a>
 Why this works
</h2>

With this approach, you can:

<ul>
<li>Test efficient thread separation (for schedulers like Bree) during development.</li>
<li>Avoid messy hacks with Node's experimental loaders.</li>
<li>Ensure a seamless transition from development to build.</li>
</ul>

But, you must follow real chunk path for after-built worker!

Happy node.js-ing!


 </div>
 




 </article>

 

 
 </div>
 </main>

 
 </div></div>

Ukjin Yang

Have you encountered this frustrating error since updating to Node.js 20?
TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for src/App.ts
This isn't just a minor glitch; it’s a long-standing issue in the ecosystem. You can see the ongoing discussion here:
TypeStrong/ts-node#2100
The problem is especially painful when trying to run .ts files using Worker. No matter what you try, that error often greets you. Even tools like ts-worker from Bree don't fully support ESM yet, leaving many of us in a tough spot.
But there is a way out! If you are using Vite in your environment, the solution is closer than you think. The Vite team provides vite-node, which allows you to run scripts within your Vite environment.
One tricky part remains: Node.js Worker still primarily expects .js or .mjs extensions. To bridge this gap, we'll use a small wrapper strategy.
Here’s our setup:
vite-node
A worker_wrapper.mjs file
parent.ts and child.ts
It sounds a bit complex, but it's actually quite simple once you see the code.
worker_wrapper.mjs
This file uses the vite-node programmatic API to load and execute our TypeScript worker.
import { workerData } from 'node:worker_threads';
import { createServer } from 'vite';
import { ViteNodeRunner } from 'vite-node/client';
import { ViteNodeServer } from 'vite-node/server';
import { installSourcemapsSupport } from 'vite-node/source-map';
// create vite server
const server = await createServer({
  optimizeDeps: {
    // It's recommended to disable deps optimization
    noDiscovery: true,
    include: undefined,
  },
});
// create vite-node server
const node = new ViteNodeServer(server);
// fixes stacktraces in Errors
installSourcemapsSupport({
  getSourceMap: (source) => node.getSourceMap(source),
});
// create vite-node runner
const runner = new ViteNodeRunner({
  root: server.config.root,
  base: server.config.base,
  // when having the server and runner in a different context,
  // you will need to handle the communication between them
  // and pass to this function
  fetchModule(id) {
    return node.fetchModule(id);
  },
  resolveId(id, importer) {
    return node.resolveId(id, importer);
  },
});
// execute the file
await runner.executeFile(workerData.jobpath);
// close the vite server
await server.close();
parent.ts
When initializing the Worker instance, we point it to worker_wrapper.mjs instead of the .ts file directly. We pass the actual target path via workerData.
import { Worker } from 'node:worker_threads';
import path from 'node:path';
// in Vite, you should declare __dirname yourself.
const worker = new Worker('./worker_wrapper.mjs', {
  workerData: {
    scriptPath: path.resolve(__dirname, './child.ts'),
  },
});
worker.on('message', (msg) => console.log('From Worker:', msg));
child.ts
This is where your actual worker logic lives. You can write pure TypeScript here!
import { parentPort } from 'node:worker_threads';
const heavyTask = (): string => {
  return "Task Completed in TypeScript!";
};
parentPort?.postMessage(heavyTask());
With this approach, you can:
Test efficient thread separation (for schedulers like Bree) during development.
Avoid messy hacks with Node's experimental loaders.
Ensure a seamless transition from development to build.
But, you must follow real chunk path for after-built worker!
Happy node.js-ing!

node.js Worker thread with Typescript

댓글