PR #93432: Fix Turbopack worker_threads URL resolution

• Repository: vercel/next.js
• Author: publictheta
• State: open | merged: False
• Link: https://github.com/vercel/next.js/pull/93432

Description (problem / solution / changelog)

Fixes #93427

What?

This fixes Turbopack's handling of Node.js worker_threads entries created with a URL object:

new Worker(new URL('./worker.ts', import.meta.url))

Turbopack was resolving this form with the same project-root context used for string/path worker entries. That makes relative URL worker entries fail when the relative URL should be resolved from the module that constructs it.

This PR keeps the existing behavior for string/path Node.js workers, but resolves relative URL worker entries from the module that creates the URL.

Why?

The issue reports a regression where this pattern worked in [email protected], but fails in [email protected] and [email protected]:

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

The failure happens before the app can build because Turbopack tries to resolve the relative worker entry from the wrong context:

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

Node.js documents Worker's filename argument as accepting either a string path or a WHATWG URL object. Relative string paths are resolved relative to the current working directory. By contrast, new URL(relative, import.meta.url) constructs a URL by resolving the relative specifier against the importing module's URL.

webpack also documents new Worker(new URL("./worker.js", import.meta.url)) as the supported Node.js worker_threads syntax. Matching that documented pattern avoids treating URL-object workers as if they were string-path workers.

How?

In turbopack-ecmascript worker reference analysis:

• Detect relative JsValue::Url entries passed to the Node.js Worker constructor.
• Use the importing module's parent directory as the resolution context for those URL entries.
• Keep the existing traced project directory context for string/path worker entries and other Node.js worker forms.

This keeps the fix scoped to the URL-object case from the issue while preserving the existing behavior for string-path workers.

Tests

Added an e2e regression test to the existing Turbopack-specific node-worker-threads suite:

test/e2e/app-dir/node-worker-threads

The new test covers a Route Handler that creates a worker with:

new Worker(new URL('../../worker-dir/url-worker.ts', import.meta.url))

Verified locally:

cargo fmt --check --package turbopack-ecmascript
cargo check --package turbopack-ecmascript
pnpm build-all
pnpm test-dev-turbo test/e2e/app-dir/node-worker-threads/node-worker-threads.test.ts
pnpm test-start-turbo test/e2e/app-dir/node-worker-threads/node-worker-threads.test.ts

Changed files

• test/e2e/app-dir/node-worker-threads/app/api/url-worker-test/route.ts (added, +42/-0)
• test/e2e/app-dir/node-worker-threads/app/worker-dir/url-worker.ts (added, +9/-0)
• test/e2e/app-dir/node-worker-threads/node-worker-threads.test.ts (modified, +8/-0)
• turbopack/crates/turbopack-ecmascript/src/references/mod.rs (modified, +11/-2)