feat: support node workers out of the box

[prathameshnetake]

Description

• Support Node workers out of the box. The current version throws an error "Worker is not defined".
• Chunk path relative to the module that calling it

Additional context

This need basepath to be unset in config if target is node

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

[antfu]

Can you explain a bit about the use case of this feature?

[prathameshnetake]

Hi @antfu

Assume following code

// worker.js

import { parentPort } from "worker_thread"

parentPort.on("message", () => {
  // some heavy work in thread
  ...
  parentPort.postMessage("result")
}

// main.js

import MyWorker from "./worker.js?worker"

const worker = new MyWorker()
worker .postMessage("some data");
worker .on("message", result => {
 // get result here
 console.log(result)
}

The current "Vite" version assumes Worker class on window

Problems with Node

• Generated bundle file just cannot find a declaration for the "Worker" class and hence generate an error "Worker is not defined".
• Current version emits worker chunk by name config.base + name + postfix -> "/worker.js" ( assuming default base "/"). In generated bundle worker path will be "new Worker('/worker.js')". In the case with node, it will be resolved from the root path of the OS e.g "C:" in windows.

Solutions

• We can check if the build target is a node and add an import statement for "Worker" from "worker_thread" assuming the user will add external built-in dependencies.
• Resolve worker path relative from module who calls it using __dirname

This will let us use worker for node js without hassle.
Also, we can use typescript to define and use workers in Node.js import MyWorker from "./worker.ts?worker"

[antfu]

Would like to know the scenario why would you want to bundle your node app using Vite? Electron or some SSR?

[prathameshnetake]

@antfu I am using this for the electron app in typescript having some heavy ML work on worker threads.

[antfu]

I think the scenario makes sense. @prathameshnetake Can you add some tests for this PR? Thanks

[prathameshnetake]

@antfu Sure. I will make the test asap. Thanks

[prathameshnetake]

@antfu Added tests. Please have a look. Thanks

[Caleb-Irwin]

Is this PR dead?

[prathamesh-toptal]

I will check if the intent of this PR is already in there

[garrettmflynn]

Has anyone developed a good workaround for this? Trying to create a library that works both on browser and Node—but this remains a persistent challenge.

[feenn]

Any updates for this PR?

[heygrady]

I'm not sure if this PR is still being considered, but I've come across a relevant use-case where the lack of support for worker_threads in Vite and Vitest is becoming a bottleneck. I'm using Vitest to test a Node package. Vitest defaults to 'node' as the environment (testTransformMode set to ssr: true). I'm facing issues when trying to work with worker_threads.

https://vitest.dev/config/#environment
https://vitest.dev/config/#testtransformmode

My code, which is successfully built using SWC, fails during the testing phase in Vitest. The error message reads "Cannot find module," although the path specified is correct. Here's a simplified snippet:

import { Worker } from 'node:worker_threads'

// workerScript.ts exists in the correct location
const worker = new Worker(new URL('./workerScript.js', import.meta.url))

The lack of support for worker_threads means that Vite projects cannot use worker_threads in their SSR apps. As a side effect, it also means that Vitest users cannot test code that uses worker_threads.

As a temporary measure, I've managed to circumvent the issue by pre-compiling my code and then running the tests against the output in the dist folder, instead of directly using the src folder. While this does allow my tests to run, it undermines one of the main advantages of using Vitest, which is to streamline and simplify the testing process without requiring a separate build step.

[yunsii]

I want to use Vite library mode to bundle a node target package with worker pool, so it means Vite still not support for now? 😂

[rxliuli]

Maybe try using the plugin directly? Just like electron-vite does

https://github.com/alex8088/electron-vite/blob/master/src/plugins/worker.ts

[Shyam-Chen]

I think it's because Vite is primarily focused on frontend development. However, I wish Vite could support node:worker_threads, as I use Vite not only for frontend development but also for backend development with Node.js, vite-node, Fastify and vite-plugin-fastify. If it had this support, it would make working with Bree much more convenient. I could use TypeScript without having to rely on vite-plugin-static-copy to copy JavaScript files to the dist folder.

---

import { Worker } from 'node:worker_threads'

// workerScript.ts exists in the correct location
const worker = new Worker(new URL('./workerScript.js', import.meta.url))

This can be used during Vite development, but it cannot be executed properly with the build command and requires vite-plugin-static-copy to handle it. By the way, during development, Workers can also use TypeScript, but the build command cannot handle it. So, I have to write JavaScript and then copy it to the dist folder.

[jarrodpayne]

I think it's because Vite is primarily focused on frontend development. However, I wish Vite could support node:worker_threads, as I use Vite not only for frontend development but also for backend development with Node.js, vite-node, Fastify and vite-plugin-fastify. If it had this support, it would make working with Bree much more convenient. I could use TypeScript without having to rely on vite-plugin-static-copy to copy JavaScript files to the dist folder.

import { Worker } from 'node:worker_threads'

// workerScript.ts exists in the correct location
const worker = new Worker(new URL('./workerScript.js', import.meta.url))

This can be used during Vite development, but it cannot be executed properly with the build command and requires vite-plugin-static-copy to handle it. By the way, during development, Workers can also use TypeScript, but the build command cannot handle it. So, I have to write JavaScript and then copy it to the dist folder.

@Shyam-Chen Did you ever find a better solution to these issues? I'm just now stumbling across these as well. I'm trying to utilize vite-node for Node.js server development using TypeScript.

[Shyam-Chen]

@Shyam-Chen Did you ever find a better solution to these issues? I'm just now stumbling across these as well. I'm trying to utilize vite-node for Node.js server development using TypeScript.

@paynecodes My current solution is to use vite-plugin-static-copy to copy the JavaScript Worker file that I have written.

[sirlancelot]

Will this ever land in Vite? I'm finding this feature to be more and more essential as I use vite-node in my TypeScript projects. For now my worker scripts are simple enough that I can get away with them being small JS files, but it's very limiting and I know Vite can do better.

[sarendipitee]

I'd really like to see this land in vite. If any maintainers are hovering around, could you pop in a quick comment about why we can't have our nice things?

[hi-ogawa]

We discussed this topic in a recent meeting. While we think this is a nice feature and welcome a PR, these are feedback about the API and implementation:

• Instead of reusing the same ?worker import, we should introduce a new query ?nodeWorker.
• Current PR seems to support only build, but we should support development to accept this as a feature.
  • Other known plugin implementation seems to be also build only, such as https://github.com/alex8088/electron-vite/blob/ad50cba49561bf306604fc983f82e81a4eb1240c/src/plugins/worker.ts

I'm not sure how dev implementation would looks like, but Vitest's worker emulation https://github.com/vitest-dev/vitest/tree/main/packages/web-worker might provide some hint. It spawns an independent module runner to execute worker code.

[prathameshnetake]

Thanks. I can work on the given suggestions and will update the PR accordingly @hi-ogawa

[aviallon]

@prathameshnetake Do you need sponsoring to work on this feature?

FYI : https://github.com/aheissenberger/vite-plugin-node-worker

[jlarmstrongiv]

I would love to see support land for node worker threads land in Vite! I’ve tried all of the plugin examples, but not of them worked for me.

[adworacz]

Per @aviallon's comment, I tried https://github.com/aheissenberger/vite-plugin-node-worker, and it works, as long as I pin to version 1.0.5.

Looking forward to proper native support!

[aviallon]

Yes, now that SvelteKit and other full stack frameworks start getting some traction, this is slowly becoming more and more of an issue.

[prathameshnetake]

@hi-ogawa @antfu As code of this PR lagging far behind. I created new PR #21160 which covers this use case with all the feedbacks. Please review