Turbopack fails to resolve node:worker_threads Worker entries created with new URL(..., import.meta.url)

[publictheta]

Link to the code that reproduces this issue

https://github.com/publictheta/next-worker-url-repro

To Reproduce

1. Clone and install the reproduction:

   git clone https://github.com/publictheta/next-worker-url-repro.git
   cd next-worker-url-repro
   pnpm install

2. Run the build comparison:

   pnpm repro

3. Output:

   apps/next-16-1 build: ▲ Next.js 16.1.7 (Turbopack)
   apps/next-16-1 build: ✓ Compiled successfully
   apps/next-16-1 build: Done
   
   apps/next-16-2 build: ▲ Next.js 16.2.4 (Turbopack)
   apps/next-16-2 build: Module not found: Can't resolve '../../worker-entry.mjs'
   apps/next-16-2 build: Module not found: Can't resolve '../../worker-entry.mts'
   apps/next-16-2 build: Failed
   
   apps/next-canary build: ▲ Next.js 16.3.0-canary.8 (Turbopack)
   apps/next-canary build: Module not found: Can't resolve '../../worker-entry.mjs'
   apps/next-canary build: Module not found: Can't resolve '../../worker-entry.mts'
   apps/next-canary build: Failed
   

Current vs. Expected behavior

The reproduction creates Node.js workers from a Route Handler using URL objects:

new Worker(new URL("../../worker-entry.mjs", import.meta.url))
new Worker(new URL("../../worker-entry.mts", import.meta.url))

node:worker_threads accepts a URL object as the Worker filename. In this form, ../../worker-entry.mjs should be resolved relative to the module containing import.meta.url, i.e. the Route Handler module.

Current behavior:

With next@16.2.4 and next@16.3.0-canary.8, Turbopack tries to resolve the relative URL worker entry from the wrong context and fails before the app can build:

Module not found: Can't resolve '../../worker-entry.mjs'
Module not found: Can't resolve '../../worker-entry.mts'

Expected behavior:

Turbopack should resolve URL object worker entries relative to the module that constructs the URL, while preserving the existing behavior for string/path Node.js workers.

This worked in next@16.1.7, fails in next@16.2.4, and is still present in next@16.3.0-canary.8.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.4.0: Thu Mar 19 19:32:59 PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_T8122
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 25.5.0
  npm: 11.12.1
  Yarn: N/A
  pnpm: 10.33.0
Relevant Packages:
  next: 16.2.4 // Latest available version is detected (16.2.4).
  eslint-config-next: N/A
  react: 19.2.5
  react-dom: 19.2.5
  typescript: N/A
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Module Resolution, Turbopack

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local)

Additional context

No response

[enmanuelcanelon]

This is indeed a regression introduced in the 16.2.x Turbopack module resolution pipeline.

The Root Cause

The underlying issue stems from how Turbopack's AST analyzer currently handles the static extraction of the new Worker(new URL(..., import.meta.url)) pattern for node:worker_threads.

When Turbopack statically analyzes this syntax, it attempts to resolve the relative path (../../worker-entry.mjs) against the context of the emitted server chunk instead of the original source module. Since the output directory structure flattens or shifts relative paths, the resolver throws a Module not found error before the build can even finish. In 16.1.7, this strict static tracing wasn't intercepting worker_threads URLs in this exact aggressive manner.

The Workaround (until patched in canary)

While we wait for a patch to the Turbopack Rust core (tree_shake/graph.rs and the worker analyzer), you can bypass the static analyzer and still maintain functional resolution in Node.js.

By separating the URL instantiation from the new Worker() call, Turbopack's static AST matcher will skip the node, and it will be evaluated at runtime by Node.js natively:

// Extracting it to a variable prevents Turbopack from aggressively resolving it at build time
const workerUrl = new URL("../../worker-entry.mjs", import.meta.url);
const worker = new Worker(workerUrl);

[publictheta]

Thanks @enmanuelcanelon for the workaround!

I poked at the Turbopack source a bit and put together a draft PR (#93432) — sharing in case it's useful, but the maintainers should obviously have the final word.

From what I could see, the worker_threads analyzer uses a single resolution context (the Next.js project directory — i.e. the directory next build runs in, where next.config.js lives; in a monorepo this is the app directory like apps/web/, not the workspace root) for every form of the Worker argument:

next.js/turbopack/crates/turbopack-ecmascript/src/references/mod.rs

Lines 1976 to 1977 in 008e2e4

	// WorkerThreads resolve filepaths relative to the process root
	get_traced_project_dir().await?,

That works for string paths (Node.js resolves them against process.cwd()), but for new URL(rel, import.meta.url) the relative specifier should be resolved against the importing module instead. The bundling support landed in #88967 (first stable in v16.2.0), which lines up with the bisect.

Another possible workaround

If the URL form is inconvenient to refactor away from, another option is a string path from the Next.js project directory (not relative to the source module):

// repro layout: project dir = apps/<app>/, worker at apps/<app>/app/worker-entry.mjs
new Worker("app/worker-entry.mjs")

This stays on the code path that already works. Verified locally with next@16.2.4, both with the repro's app/ layout and with a src/app/ variant (new Worker("src/app/worker-entry.mjs")); /api/worker returns the expected response in both cases.

Just a suggestion alongside @enmanuelcanelon's; whichever fits better. The draft PR (#93432) tries the minimal fix on the analyzer side — happy to revise based on maintainer feedback.

[enmanuelcanelon]

Thanks @enmanuelcanelon for the workaround!

I poked at the Turbopack source a bit and put together a draft PR (#93432) — sharing in case it's useful, but the maintainers should obviously have the final word.

From what I could see, the worker_threads analyzer uses a single resolution context (the Next.js project directory — i.e. the directory next build runs in, where next.config.js lives; in a monorepo this is the app directory like apps/web/, not the workspace root) for every form of the Worker argument:

next.js/turbopack/crates/turbopack-ecmascript/src/references/mod.rs

Lines 1976 to 1977 in 008e2e4

// WorkerThreads resolve filepaths relative to the process root
get_traced_project_dir().await?,
That works for string paths (Node.js resolves them against process.cwd()), but for new URL(rel, import.meta.url) the relative specifier should be resolved against the importing module instead. The bundling support landed in #88967 (first stable in v16.2.0), which lines up with the bisect.

Another possible workaround

If the URL form is inconvenient to refactor away from, another option is a string path from the Next.js project directory (not relative to the source module):

// repro layout: project dir = apps//, worker at apps//app/worker-entry.mjs
new Worker("app/worker-entry.mjs")
This stays on the code path that already works. Verified locally with next@16.2.4, both with the repro's app/ layout and with a src/app/ variant (new Worker("src/app/worker-entry.mjs")); /api/worker returns the expected response in both cases.

Just a suggestion alongside @enmanuelcanelon's; whichever fits better. The draft PR (#93432) tries the minimal fix on the analyzer side — happy to revise based on maintainer feedback.

Excellent deep dive, @publictheta! Finding the specific lines in mod.rs (1976-1977) really clarifies why the resolution context was shifting to the project root instead of the module context.

Your draft PR (#93432) looks like the right path forward to handle import.meta.url correctly in the analyzer. Also, thanks for the alternative string-path workaround; it’s a great 'Plan B' for those who want to avoid the URL object entirely.

Looking forward to seeing this merged!