-
-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specification of mf-manifest.json #2496
Comments
Yessss. I'm busy implementing federation into esbuild and the manifest is one remaining part. You can check my pr that open if you want to see my esbuild implementation. Also can you dm me on twitter? I added a new api called create container which lets you dynamically create my container interfaces at runtime. |
I just realized you're from intuit and AppFabric team. I think Zack C is working with you guys |
Here is the specification:
|
This is fantastic. Are all of these fields used by the federation runtime ? Is there a subset of the fields which are strictly required ? |
I believe all fileds are used. some by options like preloadRemote, others are used for loadRemote etc. I dont think we pack any additional data in here other than whats directly needed for all features of the runtime to function |
@ScriptedAlchemy If we are consuming multiple exposed modules from a remote, then each of those gets listed separately on the remotes array in the manifest. Why is that so ??? There can only be a single version of a remote that one consumer can use, right ?? When a container does this, there's no way for a bundler to unambiguously resolve this to different remotes. import Button, { someThingElse } from 'project-b/button';
import Link, { someThingDifferent } from 'project-b/link'; Hence, why can't we simplify the remotes array to be: "remotes": [
{
"federationContainerName": "http://localhost:8080/packages/examples/project-b/dist/rspack/esm/my-remote-entry.js",
"moduleNames": ["button", "link"],
"alias": "project-b",
"entry": "*"
},
], |
I had a quick look at the esbuild implementation which also generates the manifest here It only uses the module federation config provided by the user which doesn't have sufficient information about the "exposed" modules which are used from remotes. For eg. in my case I have the following federation config: remotes: {
'project-b': 'https://localhost:8080/remoteEntry.js'
} and I consume 2 exposed modules from the remote: import Button, { someThingElse } from 'project-b/button';
import Link, { someThingDifferent } from 'project-b/link'; |
Clear and concise description of the problem
For a build tool plugin which is implementing module federation (for e.g. rollup-plugin-module-federation), if it wants to generate the manifest file, what's the specification it should adhere to ?
The lack of specification for manifest protocol
Suggested solution
A specification for
mf-manifest.json
should be published so that all bundler plugins can adhere to that.Or a utility module/function should be exposed via the SDK or runtime or appropriate package so that build tools can use that to generate and emit the file as part of the build process.
Alternative
No response
Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: