Native dependencies management
For example, React Native itself will be a native dependency of the mobile application. It contains some native code that is going to be compiled and shipped within the binary of the application. Given that it is a native dependency, there can be only one version of it included in the mobile application at any given time. An iOS or Android mobile application cannot include two versions of the same native dependency. To illustrate this, A mobile application cannot contain React Native 0.42.0 and React Native 0.43.0 at the same time. This is not a restriction of Electrode Native, nor React Native, but just the way mobile applications work regarding native dependencies.
On top of React Native itself, other native dependencies used by MiniApps can be either third-party React Native native modules supported by the platform (
react-native-mapsfor example) or can be platform-generated APIs or API implementations.
Because of this constraint and the fact that the Electrode Native platform allows you to package multiple MiniApps from different repositories into a single native library, Electrode Native offer support to help align the native dependency versions across all MiniApps as well as guarantees that no MiniApp with a non-aligned native dependency version will make its way into your mobile application.
This support is provided through two modules of our platform: the Electrode Native manifest and the Electrode Native cauldron.
The manifest is a GitHub repository containing data used by Electrode Native. The data can be updated at any time without having to wait for the next platform release.
This section describes the
manifest.jsonfile that is stored in the Electrode Native manifest repository.
manifest.jsonfile contains a list of native dependencies along with their versions that all of your MiniApp(s) should be aligned on. When you use the
manifest.jsonfile. If the dependency is declared in the manifest, Electrode Native installs the specific version listed in the
manifest.jsonfile. If the dependency is not part of the manifest, then Electrode Native will issue a warrning.
Electrode Native also queries the manifest repository whenever you use the
ern create-miniappcommand to know which version of React Native to use.
Thus any MiniApp developed with Electrode Native and using
ern addcommand to add dependencies, will be properly aligned to the same native dependencies versions. Please note that not using
ern addwill not cause issues, as long as you ensure that the native dependencies versions in your MiniApps package.json are aligned.
By default, Electrode Native will query the master public manifest that is maintained by our core team for any open source native dependency. Electrode Native also allows to override the master manifest with your own private manifest. This is helpful if you also work with private, non-open sourced native dependencies or if you want to use different dependencies versions alignments.
The Electrode Native cauldron is also a GitHub repository and at its core is the
cauldron.jsonfile. However, unlike the manifest, the cauldron should not be updated manually. The cauldron should only be accessed and updated using the
ern cauldronsubcommands. The cauldron repository will also be your own, as a cauldron is bound to a mobile application.
The cauldron is a simple document database, which doesn't come with the downside of having to install and set it up on a dedicated box, as it is just hosted in a git repository.
For each mobile application version, there will be a corresponding entry in the cauldron database. For example,
Walmart iOS 17.14or
Walmart Android 17.10.0. The cauldron stores specific information pertaining to each version of your mobile application, mostly the following :
- A list of all the MiniApps (and their versions) that are part of any given version of your mobile application(s))
- A list of all native dependencies (and their versions) used by these MiniApps
This is mainly all what's needed for Electrode Native to generate a container library.
Every MiniApp that needs to be added to your mobile application will first need to be added to the cauldron. The cauldron, in addition of keeping track of what is included in your mobile application versions, also acts as a "gatekeeper" to verify native dependencies versions before adding a MiniApp version to a Container (or deliver it through an OTA update).
Because the cauldron verifies which MiniApps versions and native dependencies versions are part of any given mobile application version, it can perform necessary version control checks whenever a MiniApp needs to be added to a mobile application version. Before allowing entry of the MiniApp in the cauldron, checks are performed to ensure that the versions of the native dependencies used by the MiniApp do not conflict with current native dependencies included in the targeted mobile application version. This should not happen often if MiniApps are correctly created based on a manifest--but this can happen, so we prefer to be extra cautious and perform final checks at the cauldron level.
All OTA MiniApps updates move through the cauldron first as well so that Electrode Native verifies whether or not it contains any conflicting native dependencies versions with the targeted mobile application version.