[Feature]: add support for multiple MF configs

[valorkin]

Contact Details (Optional)

No response

What's the current behavior?

only one MF config is supported

• currently we store only one entry point per builder config

What's the expected behavior?

we should support several MF configs per config file with only one zephyr plugin added
for each MF config:

• we should store each entry point
• update how we store and resolve dependencies

Further research

• how many entry points will affect dependency resolution?
• how to choose default one? first MF config per app?
• should we introduce name conventions?

Feature usage

No response

Related external product

No response

Additional information (Optional)

No response

[valorkin]

todo: add sub issues per builder type

[zmzlois]

What's the current behavior?

only one MF config is supported

• currently we store only one entry point per builder config

What's the expected behavior?

we should support several MF configs per config file with only one zephyr plugin added for each MF config:

• we should store each entry point

absolutely.

• update how we store and resolve dependencies

right now how we store it allows one-to-many-to-one: host -> remotes -> mf_config, propose to modify it to change them to one-to-many-to-many: host -> remotes -> mf_configs.
more discussion below under further research section.

---

Further research

---

• how many entry points will affect dependency resolution?

Is this a question regarding here?

const resolve_entry = [
      fetch(edgeUrl, { method: 'HEAD' })
        .then(() => edgeUrl)
        .catch(() => false),
    ];

    Promise.race(resolve_entry)
      .then((remoteUrl) => {
        if (typeof remoteUrl !== 'string') return;
        const _win = _windows as unknown as Record<string, unknown>;

        if (typeof _win[remote_name] !== 'undefined') {
          return resolve(_win[remote_name]);
        }

If this is a question of how fast it can settle during a race without breaking the application I guess we do need to test this with an actual example with a POC with infra/backend support somewhere ready (unless I am not understanding the question correctly)

Note that before accumulating runtime data we couldn't handle auto-fallback or resolving another one during runtime

---

• how to choose default one? first MF config per app?

Although I'd add more comments when another round of interview
agree to first MF config become the default one, but also thinking hypothetically we should allow user to mutate and select different mf config (additional field in database also required, also need to put extra attention with packageJsonName and mfConfig.remotes.name ):

1. within code by changing configuration
Most recommended, have a record of how things are within code

// default
remotes: {
   remoteName: 'https://localhost:3000/remoteEntry.js'
}

// changing remote
remotes: {
   remoteNameFallback: 'https://localhost:3000/remote-entry-fallback.js'
}

// we could possibly also using this
remotes: {
       // package.json name
        'manifest-provider':
           // different version of the provider mf config
          'manifest_provider_fallback@http://localhost:3011/remote-entry-fallback.js',
     },

// mf config in vite 
remotes: {
    // package.json name
     remoteApp: {
           // mf config version's name
           name: 'remoteAppFallback', 
           entry: 'remoteEntryFallback.js'
        }
   }

---

2. Always resolve to the first mf config, but able to change via CLI

less recommend, opaque, no apparent record within code other than they can see it from organization changelog (a feature still in design phase), if we are doing this we also need to show what are the available configs and remote entries on UI i believe?

# listing all the remotes of a host application and the default configurations
zephyr app <host-app-id> show remotes
# show all mf configs available under one remote return which one is default, id, entry etc
zephyr app <remote-app-id> show configs
# changing default config
zephyr app <remote-app-id> config default <mf-config-id>

3. changing via UI/display mf config options via UI
if users are able to change which default to resolve to on UI would be less recommended, has no trace for application, but i can see a place where we provide a copy-paste snippet for user for each config that can be used in option 1. require UI to show all available config. Again a deployment summary page sounds good to fit in this scenario cc @swalker326

---

• should we introduce name conventions?

related to validity?

In any case we should? MF specify user should be using a name that's able to resolved as javascript identifier, while underscore within a name might not be able to resolve to a valid URL. Naming convention and validity was checked in one of the versions in Re.pack plugin but not applied to all plugins at the moment.

related to how we are able to identify remote name, remote's mf config's version?

• for web: web_host, webHost, webhost are all valid names, web-host or web.host are not valid names
• for mobile: the convention is MobileHost, while other names also works but they are less preferred because of pods/android manifest
• for mf config with different usage: app_name_fallback, appNameDeprecated , app_name_vite/app_name_webpack to identify which version is build for which host, and what purposes?

Plugin utils

if we are also introducing naming conventions, we should also add additional logging information:

1. Default remote diverge from current application config and notify user if the default was modified from somewhere else
2. You are requiring remote name with mf config version xx with entry xx
3. This application has multiple mf config, you can copy snippet from URL xxx and modify remote configuration by changing app name and remote entry
4. more TBD

thoughts? @swalker326 @ryok90 @jbroma

[zmzlois]

More writing in docs https://app.affine.pro/workspace/df6f26fd-56c9-4275-8006-5704a734c552/UfE2y97luBrI00uvWx2WN?mode=page&blockIds=cnDUSqLIOwsmFUD-GBRpD

[zmzlois]

Alternatively we give users our own solution for federation