worker: add support for Web Workers

[avivkeller]

Closes: #43583

Adds support for the Web Worker API as defined by the HTML Standard:
https://html.spec.whatwg.org/multipage/workers.html

The implementation trys to follow the specification as close as Node.js allows, so note the following differences:

• SharedWorker is not implemented. Its lifetime and sharing model depend on origins and browsing contexts, concepts that do not exist in Node.js.

• Worker scripts are loaded synchronously from the local filesystem rather than fetched over the network. As a result:

  • new Worker() and importScripts() accept only file:, data:, and blob: URLs.
  • Any other scheme throws a NotSupportedError.
  • An unreadable script throws a NetworkError (per the spec, this is emitted as an error event).
  • Redirects, nosniff, and HTTP MIME type validation are not applicable. MIME type validation is performed only for data: and blob: URLs.
  • WorkerOptions.credentials is validated for API compatibility but otherwise has no effect, since no network request is made.

• Node.js has no origin model. Consequently, concepts such as same-origin and cross-origin do not exist, and location.origin is null for file: workers.

• close() terminates the worker immediately instead of following the specification's "closing flag" algorithm. Code remaining in the current task after close() is therefore not executed.

• The worker global is the normal Node.js global object with DedicatedWorkerGlobalScope inserted into its prototype chain rather than the inverse (a fresh global created from the interface). Additionally, classic file: workers are executed through the CommonJS/ESM loaders rather than as classic scripts, so top-level declarations do not become global properties. Classic data: and blob: workers continue to execute as classic scripts.

• ErrorEvents dispatched to Worker instances include message and error, but not filename, lineno, or colno. Unhandled worker errors are also not propagated further. These are a result of the worker_threads implementation that is underneath the web workers implemantion.

• The following WorkerGlobalScope events are never dispatched:

  • languagechange, online, and offline, since these concepts do not exist in Node.js.
  • rejectionhandled and unhandledrejection, since Node.js exposes equivalent process-level events but does not implement the PromiseRejectionEvent interface or the per-rejection preventDefault() behavior required by the HTML Standard.

• On the main thread, relative worker script URLs are resolved against the current working directory because there is no document base URL. Within a worker, relative URLs resolve against the worker's own URL, matching the specification.

AI Disclaimer: I used slight AI help to resolve issues that came up during me validating the WPT tests.

TODO before merge:

• test WPT Report upload against staging.wpt.fyi with @panva

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/startup
• @nodejs/web-standards

[avivkeller]

I'm not sure if I should break the WPT additions into their own commit / PR for ease of reviewing?

You should be able to collapse the test folder to view the lib impl changes

Finally, I haven't added dedicated tests for this outside of the WPT, which should cover it.

[jasnell]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

[avivkeller]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

Broken up! c73f2fe has the actual changes

[codecov]

Codecov Report

❌ Patch coverage is 93.63799% with 71 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.13%. Comparing base (91a99c5) to head (1beb0ab).
⚠️ Report is 20 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/webworker.js	92.70%	71 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #64894 +/- ##
==========================================
- Coverage 90.32% 90.13% -0.19% 
==========================================
Files 751 752 +1 Lines 250000 251424 +1424 Branches 47231 47247 +16 ==========================================
+ Hits 225816 226628 +812 - Misses 15566 16162 +596 - Partials 8618 8634 +16 

Files with missing lines	Coverage Δ
lib/internal/blob.js	89.40% <100.00%> (-0.46%)	⬇️
...internal/bootstrap/web/exposed-window-or-worker.js	91.60% <100.00%> (-2.20%)	⬇️
lib/internal/encoding.js	96.66% <100.00%> (+0.04%)	⬆️
lib/internal/event_target.js	98.78% <100.00%> (-0.40%)	⬇️
lib/internal/main/worker_thread.js	94.91% <100.00%> (+0.55%)	⬆️
lib/internal/modules/helpers.js	98.92% <100.00%> (-0.01%)	⬇️
lib/internal/navigator.js	98.78% <100.00%> (+<0.01%)	⬆️
lib/internal/process/pre_execution.js	97.14% <100.00%> (-0.58%)	⬇️
lib/internal/webidl.js	99.12% <100.00%> (-0.34%)	⬇️
lib/internal/worker.js	96.76% <100.00%> (+0.01%)	⬆️
... and 5 more

... and 57 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

This is gargantuan. Can you add a review guide and/or split into chunks?

[panva]

I have:

• added a commit to accomodate multi-global WPT tests in the runner and reporter
• added a TODO to the description when this stabilizes to test the daily WPT Report upload against staging.wpt.fyi

[avivkeller]

This is gargantuan. Can you add a review guide and/or split into chunks?

It's only extremely large due to the added WPT tests. You can make it easier to review by

1. Not reviewing the WPT test commit (the second commit in the PR), or
2. Collapsing the test/fixtures folder in the GitHub UI

[panva]

rebased and squashed, i made no functional changes

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75836/

[avivkeller]

Landed in c7b962c...c73d0b1

[panva]

@avivkeller please follow up with a 27.x semver major flag flip. --no-experimental-* to turn off, on by default, still experimental active development.

[jimmywarting]

I see that there are some issues with supporting async, file-backed Blobs.

I wonder if this could be handled by separating the Worker’s creation from the loading of its script:

1. Create a MessageChannel first.
2. Create the Worker object without loading the script yet.
3. Return the Worker to the developer immediately.
4. The developer can now call postMessage() as usual. Those messages can be queued/deferred until the worker’s side is ready to consume them.
5. Load the worker script asynchronously, including cases where loading the script involves async operations such as fs.openAsBlob().
6. Once the script has finished loading, connect the other end of the MessageChannel and start consuming the queued messages.

This would effectively decouple the synchronous construction of the Worker from the asynchronous loading/initialization of its script, while preserving the existing postMessage() API semantics.

The MessageChannel would act as the buffer between the developer-facing Worker object and the worker runtime until the script is ready.

[avivkeller]

Closes: #43583

Adds support for the Web Worker API as defined by the HTML Standard:
https://html.spec.whatwg.org/multipage/workers.html

The implementation trys to follow the specification as close as Node.js allows, so note the following differences:

• SharedWorker is not implemented. Its lifetime and sharing model depend on origins and browsing contexts, concepts that do not exist in Node.js.

• Worker scripts are loaded synchronously from the local filesystem rather than fetched over the network. As a result:

  • new Worker() and importScripts() accept only file:, data:, and blob: URLs.
  • Any other scheme throws a NotSupportedError.
  • An unreadable script throws a NetworkError (per the spec, this is emitted as an error event).
  • Redirects, nosniff, and HTTP MIME type validation are not applicable. MIME type validation is performed only for data: and blob: URLs.
  • WorkerOptions.credentials is validated for API compatibility but otherwise has no effect, since no network request is made.

• Node.js has no origin model. Consequently, concepts such as same-origin and cross-origin do not exist, and location.origin is null for file: workers.

• close() terminates the worker immediately instead of following the specification's "closing flag" algorithm. Code remaining in the current task after close() is therefore not executed.

• The worker global is the normal Node.js global object with DedicatedWorkerGlobalScope inserted into its prototype chain rather than the inverse (a fresh global created from the interface). Additionally, classic file: workers are executed through the CommonJS/ESM loaders rather than as classic scripts, so top-level declarations do not become global properties. Classic data: and blob: workers continue to execute as classic scripts.

• ErrorEvents dispatched to Worker instances include message and error, but not filename, lineno, or colno. Unhandled worker errors are also not propagated further. These are a result of the worker_threads implementation that is underneath the web workers implemantion.

• The following WorkerGlobalScope events are never dispatched:

  • languagechange, online, and offline, since these concepts do not exist in Node.js.
  • rejectionhandled and unhandledrejection, since Node.js exposes equivalent process-level events but does not implement the PromiseRejectionEvent interface or the per-rejection preventDefault() behavior required by the HTML Standard.

• On the main thread, relative worker script URLs are resolved against the current working directory because there is no document base URL. Within a worker, relative URLs resolve against the worker's own URL, matching the specification.

AI Disclaimer: I used slight AI help to resolve issues that came up during me validating the WPT tests.

TODO before merge:

• test WPT Report upload against staging.wpt.fyi with @panva

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/startup
• @nodejs/web-standards

[avivkeller]

I'm not sure if I should break the WPT additions into their own commit / PR for ease of reviewing?

You should be able to collapse the test folder to view the lib impl changes

Finally, I haven't added dedicated tests for this outside of the WPT, which should cover it.

[jasnell]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

[avivkeller]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

Broken up! c73f2fe has the actual changes

[codecov]

Codecov Report

❌ Patch coverage is 93.63799% with 71 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.13%. Comparing base (91a99c5) to head (1beb0ab).
⚠️ Report is 20 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/webworker.js	92.70%	71 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #64894 +/- ##
==========================================
- Coverage 90.32% 90.13% -0.19% 
==========================================
Files 751 752 +1 Lines 250000 251424 +1424 Branches 47231 47247 +16 ==========================================
+ Hits 225816 226628 +812 - Misses 15566 16162 +596 - Partials 8618 8634 +16 

Files with missing lines	Coverage Δ
lib/internal/blob.js	89.40% <100.00%> (-0.46%)	⬇️
...internal/bootstrap/web/exposed-window-or-worker.js	91.60% <100.00%> (-2.20%)	⬇️
lib/internal/encoding.js	96.66% <100.00%> (+0.04%)	⬆️
lib/internal/event_target.js	98.78% <100.00%> (-0.40%)	⬇️
lib/internal/main/worker_thread.js	94.91% <100.00%> (+0.55%)	⬆️
lib/internal/modules/helpers.js	98.92% <100.00%> (-0.01%)	⬇️
lib/internal/navigator.js	98.78% <100.00%> (+<0.01%)	⬆️
lib/internal/process/pre_execution.js	97.14% <100.00%> (-0.58%)	⬇️
lib/internal/webidl.js	99.12% <100.00%> (-0.34%)	⬇️
lib/internal/worker.js	96.76% <100.00%> (+0.01%)	⬆️
... and 5 more

... and 57 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

This is gargantuan. Can you add a review guide and/or split into chunks?

[panva]

I have:

• added a commit to accomodate multi-global WPT tests in the runner and reporter
• added a TODO to the description when this stabilizes to test the daily WPT Report upload against staging.wpt.fyi

[avivkeller]

This is gargantuan. Can you add a review guide and/or split into chunks?

It's only extremely large due to the added WPT tests. You can make it easier to review by

1. Not reviewing the WPT test commit (the second commit in the PR), or
2. Collapsing the test/fixtures folder in the GitHub UI

[panva]

rebased and squashed, i made no functional changes

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75836/

[avivkeller]

Landed in c7b962c...c73d0b1

[panva]

@avivkeller please follow up with a 27.x semver major flag flip. --no-experimental-* to turn off, on by default, still experimental active development.

[jimmywarting]

I see that there are some issues with supporting async, file-backed Blobs.

I wonder if this could be handled by separating the Worker’s creation from the loading of its script:

1. Create a MessageChannel first.
2. Create the Worker object without loading the script yet.
3. Return the Worker to the developer immediately.
4. The developer can now call postMessage() as usual. Those messages can be queued/deferred until the worker’s side is ready to consume them.
5. Load the worker script asynchronously, including cases where loading the script involves async operations such as fs.openAsBlob().
6. Once the script has finished loading, connect the other end of the MessageChannel and start consuming the queued messages.

This would effectively decouple the synchronous construction of the Worker from the asynchronous loading/initialization of its script, while preserving the existing postMessage() API semantics.

The MessageChannel would act as the buffer between the developer-facing Worker object and the worker runtime until the script is ready.

[avivkeller]

Closes: #43583

Adds support for the Web Worker API as defined by the HTML Standard:
https://html.spec.whatwg.org/multipage/workers.html

The implementation trys to follow the specification as close as Node.js allows, so note the following differences:

• SharedWorker is not implemented. Its lifetime and sharing model depend on origins and browsing contexts, concepts that do not exist in Node.js.

• Worker scripts are loaded synchronously from the local filesystem rather than fetched over the network. As a result:

  • new Worker() and importScripts() accept only file:, data:, and blob: URLs.
  • Any other scheme throws a NotSupportedError.
  • An unreadable script throws a NetworkError (per the spec, this is emitted as an error event).
  • Redirects, nosniff, and HTTP MIME type validation are not applicable. MIME type validation is performed only for data: and blob: URLs.
  • WorkerOptions.credentials is validated for API compatibility but otherwise has no effect, since no network request is made.

• Node.js has no origin model. Consequently, concepts such as same-origin and cross-origin do not exist, and location.origin is null for file: workers.

• close() terminates the worker immediately instead of following the specification's "closing flag" algorithm. Code remaining in the current task after close() is therefore not executed.

• The worker global is the normal Node.js global object with DedicatedWorkerGlobalScope inserted into its prototype chain rather than the inverse (a fresh global created from the interface). Additionally, classic file: workers are executed through the CommonJS/ESM loaders rather than as classic scripts, so top-level declarations do not become global properties. Classic data: and blob: workers continue to execute as classic scripts.

• ErrorEvents dispatched to Worker instances include message and error, but not filename, lineno, or colno. Unhandled worker errors are also not propagated further. These are a result of the worker_threads implementation that is underneath the web workers implemantion.

• The following WorkerGlobalScope events are never dispatched:

  • languagechange, online, and offline, since these concepts do not exist in Node.js.
  • rejectionhandled and unhandledrejection, since Node.js exposes equivalent process-level events but does not implement the PromiseRejectionEvent interface or the per-rejection preventDefault() behavior required by the HTML Standard.

• On the main thread, relative worker script URLs are resolved against the current working directory because there is no document base URL. Within a worker, relative URLs resolve against the worker's own URL, matching the specification.

AI Disclaimer: I used slight AI help to resolve issues that came up during me validating the WPT tests.

TODO before merge:

• test WPT Report upload against staging.wpt.fyi with @panva

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/startup
• @nodejs/web-standards

[avivkeller]

I'm not sure if I should break the WPT additions into their own commit / PR for ease of reviewing?

You should be able to collapse the test folder to view the lib impl changes

Finally, I haven't added dedicated tests for this outside of the WPT, which should cover it.

[jasnell]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

[avivkeller]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

Broken up! c73f2fe has the actual changes

[codecov]

Codecov Report

❌ Patch coverage is 93.63799% with 71 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.13%. Comparing base (91a99c5) to head (1beb0ab).
⚠️ Report is 20 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/webworker.js	92.70%	71 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #64894 +/- ##
==========================================
- Coverage 90.32% 90.13% -0.19% 
==========================================
Files 751 752 +1 Lines 250000 251424 +1424 Branches 47231 47247 +16 ==========================================
+ Hits 225816 226628 +812 - Misses 15566 16162 +596 - Partials 8618 8634 +16 

Files with missing lines	Coverage Δ
lib/internal/blob.js	89.40% <100.00%> (-0.46%)	⬇️
...internal/bootstrap/web/exposed-window-or-worker.js	91.60% <100.00%> (-2.20%)	⬇️
lib/internal/encoding.js	96.66% <100.00%> (+0.04%)	⬆️
lib/internal/event_target.js	98.78% <100.00%> (-0.40%)	⬇️
lib/internal/main/worker_thread.js	94.91% <100.00%> (+0.55%)	⬆️
lib/internal/modules/helpers.js	98.92% <100.00%> (-0.01%)	⬇️
lib/internal/navigator.js	98.78% <100.00%> (+<0.01%)	⬆️
lib/internal/process/pre_execution.js	97.14% <100.00%> (-0.58%)	⬇️
lib/internal/webidl.js	99.12% <100.00%> (-0.34%)	⬇️
lib/internal/worker.js	96.76% <100.00%> (+0.01%)	⬆️
... and 5 more

... and 57 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

This is gargantuan. Can you add a review guide and/or split into chunks?

[panva]

I have:

• added a commit to accomodate multi-global WPT tests in the runner and reporter
• added a TODO to the description when this stabilizes to test the daily WPT Report upload against staging.wpt.fyi

[avivkeller]

This is gargantuan. Can you add a review guide and/or split into chunks?

It's only extremely large due to the added WPT tests. You can make it easier to review by

1. Not reviewing the WPT test commit (the second commit in the PR), or
2. Collapsing the test/fixtures folder in the GitHub UI

[panva]

rebased and squashed, i made no functional changes

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75836/

[avivkeller]

Landed in c7b962c...c73d0b1

[panva]

@avivkeller please follow up with a 27.x semver major flag flip. --no-experimental-* to turn off, on by default, still experimental active development.

[jimmywarting]

I see that there are some issues with supporting async, file-backed Blobs.

I wonder if this could be handled by separating the Worker’s creation from the loading of its script:

1. Create a MessageChannel first.
2. Create the Worker object without loading the script yet.
3. Return the Worker to the developer immediately.
4. The developer can now call postMessage() as usual. Those messages can be queued/deferred until the worker’s side is ready to consume them.
5. Load the worker script asynchronously, including cases where loading the script involves async operations such as fs.openAsBlob().
6. Once the script has finished loading, connect the other end of the MessageChannel and start consuming the queued messages.

This would effectively decouple the synchronous construction of the Worker from the asynchronous loading/initialization of its script, while preserving the existing postMessage() API semantics.

The MessageChannel would act as the buffer between the developer-facing Worker object and the worker runtime until the script is ready.

[avivkeller]

Closes: #43583

Adds support for the Web Worker API as defined by the HTML Standard:
https://html.spec.whatwg.org/multipage/workers.html

The implementation trys to follow the specification as close as Node.js allows, so note the following differences:

• SharedWorker is not implemented. Its lifetime and sharing model depend on origins and browsing contexts, concepts that do not exist in Node.js.

• Worker scripts are loaded synchronously from the local filesystem rather than fetched over the network. As a result:

  • new Worker() and importScripts() accept only file:, data:, and blob: URLs.
  • Any other scheme throws a NotSupportedError.
  • An unreadable script throws a NetworkError (per the spec, this is emitted as an error event).
  • Redirects, nosniff, and HTTP MIME type validation are not applicable. MIME type validation is performed only for data: and blob: URLs.
  • WorkerOptions.credentials is validated for API compatibility but otherwise has no effect, since no network request is made.

• Node.js has no origin model. Consequently, concepts such as same-origin and cross-origin do not exist, and location.origin is null for file: workers.

• close() terminates the worker immediately instead of following the specification's "closing flag" algorithm. Code remaining in the current task after close() is therefore not executed.

• The worker global is the normal Node.js global object with DedicatedWorkerGlobalScope inserted into its prototype chain rather than the inverse (a fresh global created from the interface). Additionally, classic file: workers are executed through the CommonJS/ESM loaders rather than as classic scripts, so top-level declarations do not become global properties. Classic data: and blob: workers continue to execute as classic scripts.

• ErrorEvents dispatched to Worker instances include message and error, but not filename, lineno, or colno. Unhandled worker errors are also not propagated further. These are a result of the worker_threads implementation that is underneath the web workers implemantion.

• The following WorkerGlobalScope events are never dispatched:

  • languagechange, online, and offline, since these concepts do not exist in Node.js.
  • rejectionhandled and unhandledrejection, since Node.js exposes equivalent process-level events but does not implement the PromiseRejectionEvent interface or the per-rejection preventDefault() behavior required by the HTML Standard.

• On the main thread, relative worker script URLs are resolved against the current working directory because there is no document base URL. Within a worker, relative URLs resolve against the worker's own URL, matching the specification.

AI Disclaimer: I used slight AI help to resolve issues that came up during me validating the WPT tests.

TODO before merge:

• test WPT Report upload against staging.wpt.fyi with @panva

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/startup
• @nodejs/web-standards

[avivkeller]

I'm not sure if I should break the WPT additions into their own commit / PR for ease of reviewing?

You should be able to collapse the test folder to view the lib impl changes

Finally, I haven't added dedicated tests for this outside of the WPT, which should cover it.

[jasnell]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

[avivkeller]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

Broken up! c73f2fe has the actual changes

[codecov]

Codecov Report

❌ Patch coverage is 93.63799% with 71 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.13%. Comparing base (91a99c5) to head (1beb0ab).
⚠️ Report is 20 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/webworker.js	92.70%	71 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #64894 +/- ##
==========================================
- Coverage 90.32% 90.13% -0.19% 
==========================================
Files 751 752 +1 Lines 250000 251424 +1424 Branches 47231 47247 +16 ==========================================
+ Hits 225816 226628 +812 - Misses 15566 16162 +596 - Partials 8618 8634 +16 

Files with missing lines	Coverage Δ
lib/internal/blob.js	89.40% <100.00%> (-0.46%)	⬇️
...internal/bootstrap/web/exposed-window-or-worker.js	91.60% <100.00%> (-2.20%)	⬇️
lib/internal/encoding.js	96.66% <100.00%> (+0.04%)	⬆️
lib/internal/event_target.js	98.78% <100.00%> (-0.40%)	⬇️
lib/internal/main/worker_thread.js	94.91% <100.00%> (+0.55%)	⬆️
lib/internal/modules/helpers.js	98.92% <100.00%> (-0.01%)	⬇️
lib/internal/navigator.js	98.78% <100.00%> (+<0.01%)	⬆️
lib/internal/process/pre_execution.js	97.14% <100.00%> (-0.58%)	⬇️
lib/internal/webidl.js	99.12% <100.00%> (-0.34%)	⬇️
lib/internal/worker.js	96.76% <100.00%> (+0.01%)	⬆️
... and 5 more

... and 57 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

This is gargantuan. Can you add a review guide and/or split into chunks?

[panva]

I have:

• added a commit to accomodate multi-global WPT tests in the runner and reporter
• added a TODO to the description when this stabilizes to test the daily WPT Report upload against staging.wpt.fyi

[avivkeller]

This is gargantuan. Can you add a review guide and/or split into chunks?

It's only extremely large due to the added WPT tests. You can make it easier to review by

1. Not reviewing the WPT test commit (the second commit in the PR), or
2. Collapsing the test/fixtures folder in the GitHub UI

[panva]

rebased and squashed, i made no functional changes

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75836/

[avivkeller]

Landed in c7b962c...c73d0b1

[panva]

@avivkeller please follow up with a 27.x semver major flag flip. --no-experimental-* to turn off, on by default, still experimental active development.

[jimmywarting]

I see that there are some issues with supporting async, file-backed Blobs.

I wonder if this could be handled by separating the Worker’s creation from the loading of its script:

1. Create a MessageChannel first.
2. Create the Worker object without loading the script yet.
3. Return the Worker to the developer immediately.
4. The developer can now call postMessage() as usual. Those messages can be queued/deferred until the worker’s side is ready to consume them.
5. Load the worker script asynchronously, including cases where loading the script involves async operations such as fs.openAsBlob().
6. Once the script has finished loading, connect the other end of the MessageChannel and start consuming the queued messages.

This would effectively decouple the synchronous construction of the Worker from the asynchronous loading/initialization of its script, while preserving the existing postMessage() API semantics.

The MessageChannel would act as the buffer between the developer-facing Worker object and the worker runtime until the script is ready.

[avivkeller]

Closes: #43583

Adds support for the Web Worker API as defined by the HTML Standard:
https://html.spec.whatwg.org/multipage/workers.html

The implementation trys to follow the specification as close as Node.js allows, so note the following differences:

• SharedWorker is not implemented. Its lifetime and sharing model depend on origins and browsing contexts, concepts that do not exist in Node.js.

• Worker scripts are loaded synchronously from the local filesystem rather than fetched over the network. As a result:

  • new Worker() and importScripts() accept only file:, data:, and blob: URLs.
  • Any other scheme throws a NotSupportedError.
  • An unreadable script throws a NetworkError (per the spec, this is emitted as an error event).
  • Redirects, nosniff, and HTTP MIME type validation are not applicable. MIME type validation is performed only for data: and blob: URLs.
  • WorkerOptions.credentials is validated for API compatibility but otherwise has no effect, since no network request is made.

• Node.js has no origin model. Consequently, concepts such as same-origin and cross-origin do not exist, and location.origin is null for file: workers.

• close() terminates the worker immediately instead of following the specification's "closing flag" algorithm. Code remaining in the current task after close() is therefore not executed.

• The worker global is the normal Node.js global object with DedicatedWorkerGlobalScope inserted into its prototype chain rather than the inverse (a fresh global created from the interface). Additionally, classic file: workers are executed through the CommonJS/ESM loaders rather than as classic scripts, so top-level declarations do not become global properties. Classic data: and blob: workers continue to execute as classic scripts.

• ErrorEvents dispatched to Worker instances include message and error, but not filename, lineno, or colno. Unhandled worker errors are also not propagated further. These are a result of the worker_threads implementation that is underneath the web workers implemantion.

• The following WorkerGlobalScope events are never dispatched:

  • languagechange, online, and offline, since these concepts do not exist in Node.js.
  • rejectionhandled and unhandledrejection, since Node.js exposes equivalent process-level events but does not implement the PromiseRejectionEvent interface or the per-rejection preventDefault() behavior required by the HTML Standard.

• On the main thread, relative worker script URLs are resolved against the current working directory because there is no document base URL. Within a worker, relative URLs resolve against the worker's own URL, matching the specification.

AI Disclaimer: I used slight AI help to resolve issues that came up during me validating the WPT tests.

TODO before merge:

• test WPT Report upload against staging.wpt.fyi with @panva

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/startup
• @nodejs/web-standards

[avivkeller]

I'm not sure if I should break the WPT additions into their own commit / PR for ease of reviewing?

You should be able to collapse the test folder to view the lib impl changes

Finally, I haven't added dedicated tests for this outside of the WPT, which should cover it.

[jasnell]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

[avivkeller]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

Broken up! c73f2fe has the actual changes

[codecov]

Codecov Report

❌ Patch coverage is 93.63799% with 71 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.13%. Comparing base (91a99c5) to head (1beb0ab).
⚠️ Report is 20 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/webworker.js	92.70%	71 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #64894 +/- ##
==========================================
- Coverage 90.32% 90.13% -0.19% 
==========================================
Files 751 752 +1 Lines 250000 251424 +1424 Branches 47231 47247 +16 ==========================================
+ Hits 225816 226628 +812 - Misses 15566 16162 +596 - Partials 8618 8634 +16 

Files with missing lines	Coverage Δ
lib/internal/blob.js	89.40% <100.00%> (-0.46%)	⬇️
...internal/bootstrap/web/exposed-window-or-worker.js	91.60% <100.00%> (-2.20%)	⬇️
lib/internal/encoding.js	96.66% <100.00%> (+0.04%)	⬆️
lib/internal/event_target.js	98.78% <100.00%> (-0.40%)	⬇️
lib/internal/main/worker_thread.js	94.91% <100.00%> (+0.55%)	⬆️
lib/internal/modules/helpers.js	98.92% <100.00%> (-0.01%)	⬇️
lib/internal/navigator.js	98.78% <100.00%> (+<0.01%)	⬆️
lib/internal/process/pre_execution.js	97.14% <100.00%> (-0.58%)	⬇️
lib/internal/webidl.js	99.12% <100.00%> (-0.34%)	⬇️
lib/internal/worker.js	96.76% <100.00%> (+0.01%)	⬆️
... and 5 more

... and 57 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

This is gargantuan. Can you add a review guide and/or split into chunks?

[panva]

I have:

• added a commit to accomodate multi-global WPT tests in the runner and reporter
• added a TODO to the description when this stabilizes to test the daily WPT Report upload against staging.wpt.fyi

[avivkeller]

This is gargantuan. Can you add a review guide and/or split into chunks?

It's only extremely large due to the added WPT tests. You can make it easier to review by

1. Not reviewing the WPT test commit (the second commit in the PR), or
2. Collapsing the test/fixtures folder in the GitHub UI

[panva]

rebased and squashed, i made no functional changes

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75836/

[avivkeller]

Landed in c7b962c...c73d0b1

[panva]

@avivkeller please follow up with a 27.x semver major flag flip. --no-experimental-* to turn off, on by default, still experimental active development.

[jimmywarting]

I see that there are some issues with supporting async, file-backed Blobs.

I wonder if this could be handled by separating the Worker’s creation from the loading of its script:

1. Create a MessageChannel first.
2. Create the Worker object without loading the script yet.
3. Return the Worker to the developer immediately.
4. The developer can now call postMessage() as usual. Those messages can be queued/deferred until the worker’s side is ready to consume them.
5. Load the worker script asynchronously, including cases where loading the script involves async operations such as fs.openAsBlob().
6. Once the script has finished loading, connect the other end of the MessageChannel and start consuming the queued messages.

This would effectively decouple the synchronous construction of the Worker from the asynchronous loading/initialization of its script, while preserving the existing postMessage() API semantics.

The MessageChannel would act as the buffer between the developer-facing Worker object and the worker runtime until the script is ready.

[avivkeller]

Closes: #43583

Adds support for the Web Worker API as defined by the HTML Standard:
https://html.spec.whatwg.org/multipage/workers.html

The implementation trys to follow the specification as close as Node.js allows, so note the following differences:

• SharedWorker is not implemented. Its lifetime and sharing model depend on origins and browsing contexts, concepts that do not exist in Node.js.

• Worker scripts are loaded synchronously from the local filesystem rather than fetched over the network. As a result:

  • new Worker() and importScripts() accept only file:, data:, and blob: URLs.
  • Any other scheme throws a NotSupportedError.
  • An unreadable script throws a NetworkError (per the spec, this is emitted as an error event).
  • Redirects, nosniff, and HTTP MIME type validation are not applicable. MIME type validation is performed only for data: and blob: URLs.
  • WorkerOptions.credentials is validated for API compatibility but otherwise has no effect, since no network request is made.

• Node.js has no origin model. Consequently, concepts such as same-origin and cross-origin do not exist, and location.origin is null for file: workers.

• close() terminates the worker immediately instead of following the specification's "closing flag" algorithm. Code remaining in the current task after close() is therefore not executed.

• The worker global is the normal Node.js global object with DedicatedWorkerGlobalScope inserted into its prototype chain rather than the inverse (a fresh global created from the interface). Additionally, classic file: workers are executed through the CommonJS/ESM loaders rather than as classic scripts, so top-level declarations do not become global properties. Classic data: and blob: workers continue to execute as classic scripts.

• ErrorEvents dispatched to Worker instances include message and error, but not filename, lineno, or colno. Unhandled worker errors are also not propagated further. These are a result of the worker_threads implementation that is underneath the web workers implemantion.

• The following WorkerGlobalScope events are never dispatched:

  • languagechange, online, and offline, since these concepts do not exist in Node.js.
  • rejectionhandled and unhandledrejection, since Node.js exposes equivalent process-level events but does not implement the PromiseRejectionEvent interface or the per-rejection preventDefault() behavior required by the HTML Standard.

• On the main thread, relative worker script URLs are resolved against the current working directory because there is no document base URL. Within a worker, relative URLs resolve against the worker's own URL, matching the specification.

AI Disclaimer: I used slight AI help to resolve issues that came up during me validating the WPT tests.

TODO before merge:

• test WPT Report upload against staging.wpt.fyi with @panva

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/startup
• @nodejs/web-standards

[avivkeller]

I'm not sure if I should break the WPT additions into their own commit / PR for ease of reviewing?

You should be able to collapse the test folder to view the lib impl changes

Finally, I haven't added dedicated tests for this outside of the WPT, which should cover it.

[jasnell]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

[avivkeller]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

Broken up! c73f2fe has the actual changes

[codecov]

Codecov Report

❌ Patch coverage is 93.63799% with 71 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.13%. Comparing base (91a99c5) to head (1beb0ab).
⚠️ Report is 20 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/webworker.js	92.70%	71 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #64894 +/- ##
==========================================
- Coverage 90.32% 90.13% -0.19% 
==========================================
Files 751 752 +1 Lines 250000 251424 +1424 Branches 47231 47247 +16 ==========================================
+ Hits 225816 226628 +812 - Misses 15566 16162 +596 - Partials 8618 8634 +16 

Files with missing lines	Coverage Δ
lib/internal/blob.js	89.40% <100.00%> (-0.46%)	⬇️
...internal/bootstrap/web/exposed-window-or-worker.js	91.60% <100.00%> (-2.20%)	⬇️
lib/internal/encoding.js	96.66% <100.00%> (+0.04%)	⬆️
lib/internal/event_target.js	98.78% <100.00%> (-0.40%)	⬇️
lib/internal/main/worker_thread.js	94.91% <100.00%> (+0.55%)	⬆️
lib/internal/modules/helpers.js	98.92% <100.00%> (-0.01%)	⬇️
lib/internal/navigator.js	98.78% <100.00%> (+<0.01%)	⬆️
lib/internal/process/pre_execution.js	97.14% <100.00%> (-0.58%)	⬇️
lib/internal/webidl.js	99.12% <100.00%> (-0.34%)	⬇️
lib/internal/worker.js	96.76% <100.00%> (+0.01%)	⬆️
... and 5 more

... and 57 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

This is gargantuan. Can you add a review guide and/or split into chunks?

[panva]

I have:

• added a commit to accomodate multi-global WPT tests in the runner and reporter
• added a TODO to the description when this stabilizes to test the daily WPT Report upload against staging.wpt.fyi

[avivkeller]

This is gargantuan. Can you add a review guide and/or split into chunks?

It's only extremely large due to the added WPT tests. You can make it easier to review by

1. Not reviewing the WPT test commit (the second commit in the PR), or
2. Collapsing the test/fixtures folder in the GitHub UI

[panva]

rebased and squashed, i made no functional changes

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75836/

[avivkeller]

Landed in c7b962c...c73d0b1

[panva]

@avivkeller please follow up with a 27.x semver major flag flip. --no-experimental-* to turn off, on by default, still experimental active development.

[jimmywarting]

I see that there are some issues with supporting async, file-backed Blobs.

I wonder if this could be handled by separating the Worker’s creation from the loading of its script:

1. Create a MessageChannel first.
2. Create the Worker object without loading the script yet.
3. Return the Worker to the developer immediately.
4. The developer can now call postMessage() as usual. Those messages can be queued/deferred until the worker’s side is ready to consume them.
5. Load the worker script asynchronously, including cases where loading the script involves async operations such as fs.openAsBlob().
6. Once the script has finished loading, connect the other end of the MessageChannel and start consuming the queued messages.

This would effectively decouple the synchronous construction of the Worker from the asynchronous loading/initialization of its script, while preserving the existing postMessage() API semantics.

The MessageChannel would act as the buffer between the developer-facing Worker object and the worker runtime until the script is ready.

[avivkeller]

Closes: #43583

Adds support for the Web Worker API as defined by the HTML Standard:
https://html.spec.whatwg.org/multipage/workers.html

The implementation trys to follow the specification as close as Node.js allows, so note the following differences:

• SharedWorker is not implemented. Its lifetime and sharing model depend on origins and browsing contexts, concepts that do not exist in Node.js.

• Worker scripts are loaded synchronously from the local filesystem rather than fetched over the network. As a result:

  • new Worker() and importScripts() accept only file:, data:, and blob: URLs.
  • Any other scheme throws a NotSupportedError.
  • An unreadable script throws a NetworkError (per the spec, this is emitted as an error event).
  • Redirects, nosniff, and HTTP MIME type validation are not applicable. MIME type validation is performed only for data: and blob: URLs.
  • WorkerOptions.credentials is validated for API compatibility but otherwise has no effect, since no network request is made.

• Node.js has no origin model. Consequently, concepts such as same-origin and cross-origin do not exist, and location.origin is null for file: workers.

• close() terminates the worker immediately instead of following the specification's "closing flag" algorithm. Code remaining in the current task after close() is therefore not executed.

• The worker global is the normal Node.js global object with DedicatedWorkerGlobalScope inserted into its prototype chain rather than the inverse (a fresh global created from the interface). Additionally, classic file: workers are executed through the CommonJS/ESM loaders rather than as classic scripts, so top-level declarations do not become global properties. Classic data: and blob: workers continue to execute as classic scripts.

• ErrorEvents dispatched to Worker instances include message and error, but not filename, lineno, or colno. Unhandled worker errors are also not propagated further. These are a result of the worker_threads implementation that is underneath the web workers implemantion.

• The following WorkerGlobalScope events are never dispatched:

  • languagechange, online, and offline, since these concepts do not exist in Node.js.
  • rejectionhandled and unhandledrejection, since Node.js exposes equivalent process-level events but does not implement the PromiseRejectionEvent interface or the per-rejection preventDefault() behavior required by the HTML Standard.

• On the main thread, relative worker script URLs are resolved against the current working directory because there is no document base URL. Within a worker, relative URLs resolve against the worker's own URL, matching the specification.

AI Disclaimer: I used slight AI help to resolve issues that came up during me validating the WPT tests.

TODO before merge:

• test WPT Report upload against staging.wpt.fyi with @panva

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/startup
• @nodejs/web-standards

[avivkeller]

I'm not sure if I should break the WPT additions into their own commit / PR for ease of reviewing?

You should be able to collapse the test folder to view the lib impl changes

Finally, I haven't added dedicated tests for this outside of the WPT, which should cover it.

[jasnell]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

[avivkeller]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

Broken up! c73f2fe has the actual changes

[codecov]

Codecov Report

❌ Patch coverage is 93.63799% with 71 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.13%. Comparing base (91a99c5) to head (1beb0ab).
⚠️ Report is 20 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/webworker.js	92.70%	71 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #64894 +/- ##
==========================================
- Coverage 90.32% 90.13% -0.19% 
==========================================
Files 751 752 +1 Lines 250000 251424 +1424 Branches 47231 47247 +16 ==========================================
+ Hits 225816 226628 +812 - Misses 15566 16162 +596 - Partials 8618 8634 +16 

Files with missing lines	Coverage Δ
lib/internal/blob.js	89.40% <100.00%> (-0.46%)	⬇️
...internal/bootstrap/web/exposed-window-or-worker.js	91.60% <100.00%> (-2.20%)	⬇️
lib/internal/encoding.js	96.66% <100.00%> (+0.04%)	⬆️
lib/internal/event_target.js	98.78% <100.00%> (-0.40%)	⬇️
lib/internal/main/worker_thread.js	94.91% <100.00%> (+0.55%)	⬆️
lib/internal/modules/helpers.js	98.92% <100.00%> (-0.01%)	⬇️
lib/internal/navigator.js	98.78% <100.00%> (+<0.01%)	⬆️
lib/internal/process/pre_execution.js	97.14% <100.00%> (-0.58%)	⬇️
lib/internal/webidl.js	99.12% <100.00%> (-0.34%)	⬇️
lib/internal/worker.js	96.76% <100.00%> (+0.01%)	⬆️
... and 5 more

... and 57 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

This is gargantuan. Can you add a review guide and/or split into chunks?

[panva]

I have:

• added a commit to accomodate multi-global WPT tests in the runner and reporter
• added a TODO to the description when this stabilizes to test the daily WPT Report upload against staging.wpt.fyi

[avivkeller]

This is gargantuan. Can you add a review guide and/or split into chunks?

It's only extremely large due to the added WPT tests. You can make it easier to review by

1. Not reviewing the WPT test commit (the second commit in the PR), or
2. Collapsing the test/fixtures folder in the GitHub UI

[panva]

rebased and squashed, i made no functional changes

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75836/

[avivkeller]

Landed in c7b962c...c73d0b1

[panva]

@avivkeller please follow up with a 27.x semver major flag flip. --no-experimental-* to turn off, on by default, still experimental active development.

[jimmywarting]

I see that there are some issues with supporting async, file-backed Blobs.

I wonder if this could be handled by separating the Worker’s creation from the loading of its script:

1. Create a MessageChannel first.
2. Create the Worker object without loading the script yet.
3. Return the Worker to the developer immediately.
4. The developer can now call postMessage() as usual. Those messages can be queued/deferred until the worker’s side is ready to consume them.
5. Load the worker script asynchronously, including cases where loading the script involves async operations such as fs.openAsBlob().
6. Once the script has finished loading, connect the other end of the MessageChannel and start consuming the queued messages.

This would effectively decouple the synchronous construction of the Worker from the asynchronous loading/initialization of its script, while preserving the existing postMessage() API semantics.

The MessageChannel would act as the buffer between the developer-facing Worker object and the worker runtime until the script is ready.

[avivkeller]

Closes: #43583

Adds support for the Web Worker API as defined by the HTML Standard:
https://html.spec.whatwg.org/multipage/workers.html

The implementation trys to follow the specification as close as Node.js allows, so note the following differences:

• SharedWorker is not implemented. Its lifetime and sharing model depend on origins and browsing contexts, concepts that do not exist in Node.js.

• Worker scripts are loaded synchronously from the local filesystem rather than fetched over the network. As a result:

  • new Worker() and importScripts() accept only file:, data:, and blob: URLs.
  • Any other scheme throws a NotSupportedError.
  • An unreadable script throws a NetworkError (per the spec, this is emitted as an error event).
  • Redirects, nosniff, and HTTP MIME type validation are not applicable. MIME type validation is performed only for data: and blob: URLs.
  • WorkerOptions.credentials is validated for API compatibility but otherwise has no effect, since no network request is made.

• Node.js has no origin model. Consequently, concepts such as same-origin and cross-origin do not exist, and location.origin is null for file: workers.

• close() terminates the worker immediately instead of following the specification's "closing flag" algorithm. Code remaining in the current task after close() is therefore not executed.

• The worker global is the normal Node.js global object with DedicatedWorkerGlobalScope inserted into its prototype chain rather than the inverse (a fresh global created from the interface). Additionally, classic file: workers are executed through the CommonJS/ESM loaders rather than as classic scripts, so top-level declarations do not become global properties. Classic data: and blob: workers continue to execute as classic scripts.

• ErrorEvents dispatched to Worker instances include message and error, but not filename, lineno, or colno. Unhandled worker errors are also not propagated further. These are a result of the worker_threads implementation that is underneath the web workers implemantion.

• The following WorkerGlobalScope events are never dispatched:

  • languagechange, online, and offline, since these concepts do not exist in Node.js.
  • rejectionhandled and unhandledrejection, since Node.js exposes equivalent process-level events but does not implement the PromiseRejectionEvent interface or the per-rejection preventDefault() behavior required by the HTML Standard.

• On the main thread, relative worker script URLs are resolved against the current working directory because there is no document base URL. Within a worker, relative URLs resolve against the worker's own URL, matching the specification.

AI Disclaimer: I used slight AI help to resolve issues that came up during me validating the WPT tests.

TODO before merge:

• test WPT Report upload against staging.wpt.fyi with @panva

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/startup
• @nodejs/web-standards

[avivkeller]

I'm not sure if I should break the WPT additions into their own commit / PR for ease of reviewing?

You should be able to collapse the test folder to view the lib impl changes

Finally, I haven't added dedicated tests for this outside of the WPT, which should cover it.

[jasnell]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

[avivkeller]

The web platform tests in this PR really ought to be separated out into a separate commit to make reviewing this easier. 1300+ files changes with 54k+ lines changed is very difficult to review in a single commit.

Broken up! c73f2fe has the actual changes

[codecov]

Codecov Report

❌ Patch coverage is 93.63799% with 71 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.13%. Comparing base (91a99c5) to head (1beb0ab).
⚠️ Report is 20 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/webworker.js	92.70%	71 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #64894 +/- ##
==========================================
- Coverage 90.32% 90.13% -0.19% 
==========================================
Files 751 752 +1 Lines 250000 251424 +1424 Branches 47231 47247 +16 ==========================================
+ Hits 225816 226628 +812 - Misses 15566 16162 +596 - Partials 8618 8634 +16 

Files with missing lines	Coverage Δ
lib/internal/blob.js	89.40% <100.00%> (-0.46%)	⬇️
...internal/bootstrap/web/exposed-window-or-worker.js	91.60% <100.00%> (-2.20%)	⬇️
lib/internal/encoding.js	96.66% <100.00%> (+0.04%)	⬆️
lib/internal/event_target.js	98.78% <100.00%> (-0.40%)	⬇️
lib/internal/main/worker_thread.js	94.91% <100.00%> (+0.55%)	⬆️
lib/internal/modules/helpers.js	98.92% <100.00%> (-0.01%)	⬇️
lib/internal/navigator.js	98.78% <100.00%> (+<0.01%)	⬆️
lib/internal/process/pre_execution.js	97.14% <100.00%> (-0.58%)	⬇️
lib/internal/webidl.js	99.12% <100.00%> (-0.34%)	⬇️
lib/internal/worker.js	96.76% <100.00%> (+0.01%)	⬆️
... and 5 more

... and 57 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

This is gargantuan. Can you add a review guide and/or split into chunks?

[panva]

I have:

• added a commit to accomodate multi-global WPT tests in the runner and reporter
• added a TODO to the description when this stabilizes to test the daily WPT Report upload against staging.wpt.fyi

[avivkeller]

This is gargantuan. Can you add a review guide and/or split into chunks?

It's only extremely large due to the added WPT tests. You can make it easier to review by

1. Not reviewing the WPT test commit (the second commit in the PR), or
2. Collapsing the test/fixtures folder in the GitHub UI

[panva]

rebased and squashed, i made no functional changes

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75836/

[avivkeller]

Landed in c7b962c...c73d0b1

[panva]

@avivkeller please follow up with a 27.x semver major flag flip. --no-experimental-* to turn off, on by default, still experimental active development.

[jimmywarting]

I see that there are some issues with supporting async, file-backed Blobs.

I wonder if this could be handled by separating the Worker’s creation from the loading of its script:

1. Create a MessageChannel first.
2. Create the Worker object without loading the script yet.
3. Return the Worker to the developer immediately.
4. The developer can now call postMessage() as usual. Those messages can be queued/deferred until the worker’s side is ready to consume them.
5. Load the worker script asynchronously, including cases where loading the script involves async operations such as fs.openAsBlob().
6. Once the script has finished loading, connect the other end of the MessageChannel and start consuming the queued messages.

This would effectively decouple the synchronous construction of the Worker from the asynchronous loading/initialization of its script, while preserving the existing postMessage() API semantics.

The MessageChannel would act as the buffer between the developer-facing Worker object and the worker runtime until the script is ready.