[Flight Parcel] Pass import maps through client references #32132
Conversation
|
I'm not sure why this would need to be attached to each client reference. Can't it be part of the "bundlerConfig"? It's basically what the other manifests are for. Is this map limited to only mapping the resources used by this particular client reference? If so, can it be part of the Webpack normally does something similar to this as well. However, a goal of the Next.js versions of this is to explicitly exclude any global manifests of all possible chunks (which is also what Meta's version does). The reason is that 1) it tends to grow unbounded for large apps and ends up loaded upfront 2) it can reveal the entirety of the app to a hacker when ideally they only see what the server sent. That's why, ideally, everything about how to load a module is the already resolved version. Since an RSC payload can update when the manifest changes without recompiling the chunks. Why do you need both the pre- and post-resolution info on the client? |
|
@sebmarkbage The import map passed here only includes mappings for resources used by the bundles in this client reference. For example if a client component references an image or dynamic imports something, it would include mappings for those. It does not include mappings for client components themselves (the client reference already has those in It also does not include mappings for the entire application, and the goal is to avoid that since those maps can be very large. This approach allows incrementally loading mappings as needed.
It could, I just merged them all into one map here. I could make each bundle in the |
|
I guess if there was a more universal ClientReference object for all bundlers the meta data would be a deeply nested object which includes id and bundles and other meta data, but since id and bundles are flat it makes sense that other custom are too for now. |
Corresponding Parcel PR: parcel-bundler/parcel#10073
Parcel avoids cascading cache invalidation by injecting a bundle manifest containing a mapping of stable bundle ids to hashed URLs. When using an HTML entry point, this is done (as of the above PR) via a native import map. This means that if a bundle's hash changes, only that bundle will be invalidated (plus the HTML itself which typically has a short caching policy), not any other bundles that reference it.
For RSCs, we cannot currently use native import maps because of client side navigations, where a new HTML file is not requested. Eventually, multiple
<script type="importmap">elements will be supported (whatwg/html#10528) (coming Chrome 133), at which point React could potentially inject them. In the meantime, I've added some APIs to Parcel to polyfill this. With this change, an import map can be sent along with a client reference, containing a mapping for any dynamic imports and URL dependencies (e.g. images) that are referenced by the JS bundles. On the client, the import map is extended with these new mappings prior to executing the referenced bundles. This preserves the caching advantages described above while supporting client navigations.