facebook/reactMITd083ec1Sep 28, 2026Report / request removal

Bundler Integrations for Server Components

Flight separates the protocol and stream machinery from the bundler-specific work of locating client and server references. The bundler integration supplies manifests, module identifiers, chunk lists, export names, and the runtime operation that loads the resulting module.

This split exists because a client reference is not executable by itself: the server must encode enough metadata for the client runtime to load the right chunks and retrieve the right export. The shown webpack integration also adapts Flight to Node streams, Web Streams, WebSockets, and form-data inputs.

Core concepts

Bundler contract

A bundler contract is the set of callbacks that translates Flight reference metadata into destination preparation, module loading, export selection, and server-reference information.

Client reference

A client reference is metadata naming a module, its export, its chunks, and sometimes whether the consumer expects an asynchronous module.

Sources: packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js:71-114, packages/react-server-dom-webpack/src/server/ReactFlightServerConfigWebpackBundler.js:45-87

Manifest

A manifest is the bundler-produced lookup used to turn a reference identifier into resolved module data; missing entries are treated as bundler errors.

Sources: packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js:71-114, packages/react-server-dom-webpack/src/server/ReactFlightServerConfigWebpackBundler.js:45-87

Chunk cache

The chunk cache is a map that prevents repeated loading of the same chunk while retaining either an in-flight promise or a completed marker.

Sources: packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js:164, packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js:198-232

Stream adapter

A stream adapter makes Flight’s internal writable destination fit the host transport, including Node streams, Web Streams, and WebSockets.

Sources: packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js:166-239, packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js:241-261, packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js:263-290, packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js:408-422

What a bundler integration must provide

The client-side contract starts by preparing the destination with the chunks named by reference metadata. prepareDestinationForModule delegates those chunks to prepareDestinationWithChunks, so the integration can arrange loading before the module is required.

Resolution then has two directions. resolveClientReference consumes a server consumer map, first looking up the module identifier and export name, then falling back to the '*' entry when a specific export is absent. It returns the resolved module ID, chunks, export name, and an async marker when isAsyncImport says the consumer expects one.

On the server, resolveClientReferenceMetadata performs the inverse manifest lookup against a client manifest. It supports identifiers containing # by splitting the export name from the module path, rejects an async ESM module loaded as a CJS proxy, and returns the ID, chunks, name, and optional async marker.

The contract also covers server references. getServerReferenceId returns serverReference.$$id, while getServerReferenceBoundArguments and getServerReferenceLocation expose the bound arguments and source location carried by the reference.

The following architecture shows the main webpack-side hand-offs visible in the supplied code.

Evidence

The client entry creates a response and starts reading the supplied stream; the module path separately uses the chunk cache, asynchronous loader, and webpack loader.

How a client reference becomes a runtime module

preloadModule walks the reference’s chunk pairs. For each uncached chunk it calls loadChunk, stores the promise in chunkCache, and later replaces that entry with null; already pending entries are reused. If the reference is asynchronous, the function waits for all chunks before calling requireAsyncModule.

requireAsyncModule calls __webpack_require__ after chunks are loaded. If the result is a promise, it instruments that promise with status, value, or reason, allowing later consumers to distinguish fulfilled and rejected modules.

requireModule calls __webpack_require__ with the resolved module ID. It unwraps an already fulfilled asynchronous module, returns the complete module for the '*' placeholder, returns the default export for the empty-name placeholder when ESM interop applies, and otherwise selects the named export.

This is why the manifest carries both chunks and an export name: chunks make the module available, while the name determines which value Flight returns. Development builds can also turn the chunk pairs into debug metadata through getModuleDebugInfo.

Sources: packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js:198-232, packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js:166-191, packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js:236-262, packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js:264-279

How the targets differ

The repository exposes separate client fork files for webpack, Turbopack, Parcel, and the unbundled Node target. Each fork names its renderer package and re-exports a target-specific Flight client configuration.

Target	Package name exposed by the fork	Bundler-specific configuration shown
`webpack`	`react-server-dom-webpack`	`ReactFlightClientConfigBundlerWebpack` and its server counterpart
`turbopack`	`react-server-dom-turbopack`	`ReactFlightClientConfigBundlerTurbopack` and its browser/server variants
`parcel`	`react-server-dom-parcel`	`ReactFlightClientConfigBundlerParcel` and `ReactFlightClientConfigTargetParcelServer`
unbundled Node	`react-server-dom-webpack`	Node stream configuration plus webpack client/server configuration

The supplied Turbopack excerpts show the same manifest shape and fallback behavior as webpack: an export name may be encoded after #, and asynchronous metadata is represented by a fourth tuple value.

The pack does not include Parcel’s resolver or runtime loader implementation, so its fork name and exported module paths are the supported evidence here, not a detailed Parcel algorithm. The unbundled Node target does show the same destination-preparation and client-resolution entry points, which demonstrates that the contract can be reused with a different transport and loading environment.

Separate packages are therefore necessary because the shared Flight runtime needs target-specific manifest interpretation, module loading, stream configuration, and renderer identity. The fork files select those combinations explicitly rather than forcing one loader implementation to understand every bundler.

How the server side carries the contract

Webpack’s server entry points pass the client manifest into createRequest, then begin work and flow the result into the host transport. renderToPipeableStream exposes pipe and abort, while renderToReadableStream creates a Web Stream whose pull calls startFlowing and whose cancel stops and aborts the request.

For Node-readable destinations, createFakeWritableFromNodeReadable forwards writes with push, ends with push(null), and propagates failures with destroy. For Web Streams, createFakeWritableFromReadableStreamController encodes strings, enqueues chunks, closes on end, and reports errors through the controller.

The same package also decodes replies using a server manifest. decodeReply creates a response, obtains its root, closes the response, and returns that root; asynchronous iterable input resolves fields or files as entries arrive and reports iterator failures globally.

Sources: packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js:166-239, packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js:333-406, packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js:408-422, packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js:263-290, packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js:675-698, packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js:700-748

How it connects

The bundler integrations sit between Server Components (Flight) and the bundler/build selection described by Rollup Bundles & Module Forks. The client stream entry points connect to the runtime protocol, while the renderer-specific forks select browser, edge, Node, and server configurations.

Server-side rendering and transport behavior connect to Server Rendering (Fizz) conceptually through streaming, but the shown APIs here are Flight-specific: they create Flight requests, flow Flight chunks, and decode Flight replies.

Sources: packages/react-server-dom-webpack/src/client/ReactFlightDOMClientBrowser.js:186-218, packages/react-client/src/forks/ReactFlightClientConfig.dom-node.js:9-16, packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js:166-239, packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js:333-406, packages/react-server-dom-webpack/src/server/ReactFlightDOMServerNode.js:675-698

Key takeaways

A bundler integration must resolve manifest metadata, prepare chunks, load modules, select exports, and expose server-reference data.
Webpack resolves a reference to module ID, chunks, export name, and optional async state, then uses __webpack_require__.
Turbopack follows the same visible manifest convention, while the supplied pack does not show Parcel’s resolver internals.
Separate packages preserve bundler-specific loaders and target-specific stream configurations behind a shared Flight contract.

Sources: packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js:63-69, packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js:71-114, packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js:198-232, packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js:236-262, packages/react-server-dom-webpack/src/server/ReactFlightServerConfigWebpackBundler.js:45-87, packages/react-server-dom-webpack/src/server/ReactFlightServerConfigWebpackBundler.js:89-94, packages/react-server-dom-turbopack/src/client/ReactFlightClientConfigBundlerTurbopack.js:118-136, packages/react-client/src/forks/ReactFlightClientConfig.dom-edge-parcel.js:10-17, packages/react-client/src/forks/ReactFlightClientConfig.dom-edge-webpack.js:10-17, packages/react-client/src/forks/ReactFlightClientConfig.dom-node.js:9-16