perf(turbopack-node): optimize worker communication with binary transport and caching

[xusd320]

This pull request refactors the way task messages are handled and transmitted between worker threads and processes in the Turbopack codebase. The main improvement is transitioning from string-based message passing to using binary data (Uint8Array/Vec<u8>/Buffer), which standardizes and streamlines serialization and deserialization across JavaScript, Rust, and WebAssembly boundaries. This change affects both the Rust backend and the JavaScript/TypeScript worker implementations.

The most important changes are:

Message Data Handling and Serialization:

• Changed all task message data fields and related APIs from String to binary types (Uint8Array, Vec<u8>, or Buffer) throughout the Rust and JS/TS code, including TaskMessage, Operation trait, and worker pool interfaces. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]
• Updated serialization and deserialization logic to use TextEncoder/TextDecoder in JS/TS and serde_json::to_vec/from_slice in Rust, ensuring consistent binary message encoding/decoding. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

Worker and Channel API Updates:

• Updated worker pool, message channel, and task channel APIs to operate on binary data instead of strings, including all send/receive methods and their implementations. [1] [2] [3] [4] [5] [6] [7] [8]

WebAssembly and NAPI Interop:

• Refactored WebAssembly and NAPI (Node.js native) bindings to use binary data for task messages, ensuring correct conversion between JS Uint8Array/Buffer and Rust Vec<u8>. [1] [2] [3] [4]

Cleanup and Consistency:

• Removed unused JSON parsing utilities and replaced them with standard binary-safe serialization methods.

These changes make the worker communication more robust and efficient, and pave the way for supporting non-UTF8 or binary payloads in the future.

[gemini-code-assist]

Summary of Changes

Hello @xusd320, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly refactors the inter-process communication within Turbopack by transitioning from string-based message passing to a more robust and efficient binary data format. This change standardizes how task messages are serialized and deserialized across JavaScript, Rust, and WebAssembly components, laying the groundwork for improved performance and future support for non-UTF8 payloads. The core impact is a more resilient and efficient communication layer for worker operations.

Highlights

• Binary Message Passing: Task messages between worker threads and processes now use binary data (Uint8Array/Vec<u8>/Buffer) instead of strings, standardizing serialization across JavaScript, Rust, and WebAssembly.
• Serialization/Deserialization Updates: JavaScript/TypeScript now uses TextEncoder/TextDecoder for encoding/decoding, while Rust employs serde_json::to_vec/from_slice to ensure consistent binary message handling.
• API Refactoring: Worker pool, message channel, and task channel APIs have been updated to operate directly on binary data, streamlining communication interfaces.
• WebAssembly and NAPI Interoperability: Bindings for WebAssembly and Node.js native (NAPI) have been refactored to correctly convert between JS Uint8Array/Buffer and Rust Vec<u8> for task messages.
• Code Cleanup: Unused JSON parsing utilities have been removed, replaced by the new binary-safe serialization methods.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively refactors the task message handling to use binary data instead of strings, which is a great improvement for performance and standardization across JavaScript, Rust, and WebAssembly. The changes are consistently applied throughout the affected modules. I have one suggestion to further improve the efficiency and type safety of the WebAssembly interop code.

[gemini-code-assist]

Using js_sys::Uint8Array::new(&data_js) creates a new Uint8Array and copies the data from data_js. This is less efficient than a direct cast and can lead to unexpected behavior if data_js is not an array-like object (e.g., if it's a number, it will create an empty buffer of that size).

A more direct, efficient, and type-safe approach is to cast the JsValue to js_sys::Uint8Array using dyn_into. This avoids an unnecessary copy and ensures that the incoming data is of the expected Uint8Array type.

Suggested change

	let data_js = js_sys::Reflect::get(&message, &"data".into())
	.map_err(|_| JsError::new("Failed to get data"))?;
	let data = js_sys::Uint8Array::new(&data_js).to_vec();
	let data = js_sys::Reflect::get(&message, &"data".into())
	.map_err(|_| JsError::new("Failed to get data"))?
	.dyn_into::<js_sys::Uint8Array>()
	.map_err(|_| JsError::new("data must be a Uint8Array"))?
	.to_vec();