[Feature]: Provide way to fetch collection of remote URLs from Zephyr

[zackarychapple]

What's the current behavior?

When working with iOS and Android there is a need to keep some level of control over which remotes and versions are used because some SDK updates may prevent a remote from being usable with OTA updates.

In order to resolve this we are creating an environment for each platform and each binary version that is shipped to the app store / play store.

This has a level of complexity that needs to be managed in the module federation config.

      new Repack.plugins.ModuleFederationPluginV2({
        remotes: {
          remote1: resolveRemote1(platform),
          remote2: resolveRemote2(platform),
          remote3: resolveRemote3(platform),
        },
      }),

There is an additional level of complexity that comes with cache keys because currently Re.Pack leverages the URL as the cache key. The caching breaks when Zephyr uses the same URL and serves different versions as the environment updates for OTA updates.

What's the expected behavior?

We're working through this with Repack via customizing the URL resolution to append the remote app version from mf-manifest.json (as well as probably independently caching those in addition to the js bundles), but it seems like a more natural solution would be something like this:

• Providing a way to fetch a collection of remote URLs from Zephyr for a platform and a version / environment.
• Zephyr deploys would change the return value of this remote url endpoint or a timestamp on it that can be used for caching
• No need for heavy Re.Pack customization

Alternatively we could look at appending the url's with semver, that would serve as the cache key, that then can be cache checked against the response from Zephyr

[kellyannhull]

Taking a stab at these:

Terms:

• Platform = ios/android/web
• version = application version (would this app know the path/versions of any dependent remotes)
• native version = ios 18.3.2/22D82 android 15
• environment = stage/production

[zackarychapple]

Taking a stab at these:

Terms:

• Platform = ios/android/web
• version = application version (would this app know the path/versions of any dependent remotes)
• native version = ios 18.3.2/22D82 android 15
• environment = stage/production

I would say platform can consist of iOS / Android / browser / server for the time being, because that will cover both the mobile and the ssg side of the story. I'm not sure if we want to say native version but that is something organizations can put in their URLs or in the semver requirements.

[zmzlois]

Want to discuss these one by one,

1. RuntimeOTA proposal

Would love to discuss with the Callstack team if this is a good approach cc @martamoc :

1. Developers can skip the environment URL, put a stable URL there or replace what dependency resolution does
2. Tag-related information (conditions for tags), and snapshots will be saved into the build output, and key information will be available within app's global context and a file
3. Repack SDK should provide a version that fits into the current environment when the conditions fit (developers) could quite possibly pass in environment to look for a specific environment)
4. The returned URL can then be used in runtime loadRemote

2. Platform

At the moment, repack provides us the platform property when resolving remote, and repack access platform by:

1. inferring from react native build
2. Taking the platform from the CLI argument
   Source

The only platform properties we can see so far from RePack are ios, android, and from the compiler it could be web or node, but we won't have iOS/Android/browser/server
The resolving sequence (for zephyr) is RePack first (available immediately before resolving dependencies, maybe can be improved later) and then compiler (available at obtaining and uploading step)

3. Cache key issue with runtime OTA

I understand that keeping a stable environment URL but updating the version under the environment is breaking the RePack cache. In RePack ^5.1.x, there is a hook shouldUpdateScript to prevent this issue from happening (source). Meaning developers can pass in the same environment URL and if content changes it won't break RePack cache.

I talked to @jbroma; there is still additional work required for both implementation and documentation

Related PR

On the topic of:

No need for heavy Re.Pack customization

Wondering how @jbroma @szymonrybczak think about this