fix(runtime) Fix snapshot for server manifest without ssr remote entry #3249
Conversation
🦋 Changeset detectedLatest commit: 734d305 The changes in this PR will be included in the next version bump. This PR includes changesets to release 27 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
✅ Deploy Preview for module-federation-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
@ScriptedAlchemy Is this(next-js manifest) remoteEntry build target node? I'm worried about the remoteEntry build target is browser which can not work on node env . |
|
Both builds produce independent manifest. 1 for browser and 1 for server. But only modernjs makes the ssr remote entry key even tho it's a cjs based build - manifest emits remoteEntry key like any standalone build |
|
@ciandt-crodrigues Instead of changing our runtime for next, i think you should look at making a new plugin or adding another hook to the next plugin on process assets, find the manifest and object assign/rewrite the keys as needed in the build plugin - just for nextjs-mf without altering the runtime itself - just mutate the asset if isServer == true |
|
@ScriptedAlchemy I can definitely do that, and it will work for me, but not everyone. I feel like this fix addresses that. while keeping both environments functional. Just let me know if you guys have interest on keeping that or not. |
|
You can send pr to nextjs-mf to merge manifest etc similarly to how modernjs does it. In the future we rspack will support multi-target outputs from a single compile, so its a short term issue imo. Feel free to add this on the plugin end of nextjs-mf so all users can use it. server info should be explicitly separate from browser info otherwise there is no way to detect the intent and it will be very easy to take production down. Because builds are not homogenous, there is no automatic way to merge manifests between the two, since we do not know where each build is emitting assets outside of how a framework does it - like next.js, we know where it goes so one could merge them, same with modernjs, if a rando wants to implement it - its not a magic feature we can enable between two build phases. Our SSR implementation in modernjs is also subject to change still, probably next quarter we will churn through another iteration and could look at this again, but either there would need to be a explicit difference in key reference for server vs client entry imo. Can likely be smoothed out in the future but will require more thought and consideration around this aspect would be needed. But def send a PR to next mf with a processasset hoook and update the asset if compiler.name === 'server' You could also find a place in our docs or make a new section somewhere to put down some tips etc around node/server + ssr based module loading with the runtime etc if you wanted to so anyone who does want to handroll had some guidance on what to do to correlate between the two builds |
|
@ScriptedAlchemy |
|
You can do it on runtime plugin. Or you could do it by adding another compiler hook like compilation.hooks.processAssets.tapAsync and actually assign the json to be ssrRemote for the compiler named server. Either will work, but if you want the json to output with right name key, you can catch the asset in webpack pipeline and adjust it then return the updated asset source which is emitted |
Description
When trying to use MF2.0 manifest as entrypoint for the nextjs-mf I found an issue where the snapshot was being rejected. the cause is that the manifest for nextjs-mf does not include a ssrRemoteEntry property (introduced a few months ago for modernJS).
This PR addresses that issue falling back to the regular remoteEntry for server-side manifests.
Related Issue
Snapshot fails for server manifest without ssr remote entry
It also completes the work started here
Types of changes
Checklist