Native dependencies mismatch
belemaire opened this issue · comments
Problem with LiveBundle is in that case the mobile application being run on the device is having native dependencies versions that are not aligned with the JS bundle.
For example if the mobile application has been built with react-native 0.60.0 but the LiveBundle has been created after bumping react-native to 0.61.0, then when scanning it, it will cause a red screen. This is because react-native does not allow mismatching react-native versions (bundle v.s native), but the problem might be less visible and cause silly side effects or weird red screens for native module versions mismatch (for example react-native-maps@1.0.0 is being used in the binary but the bundle being pushed is using react-native-maps@2.0.0).
To be able to react on this, we need to know which native dependencies (native modules + react native) and their respective versions are inside the binary, and we need to know which ones are "inside" (being used by) the bundle. For the latter, LiveBundle can easily know that because it takes care of the bundling, so it can easily detect all these native modules and versions and add that as metadata embedded within the LiveBundle. For the former, LiveBundle would need to be involved during the application build itself, and could write a metadata file somewhere in the native app that then will be read a runtime (and compared against the bundle being installed). Based on this, when we can QRCode or navigate to deep link, we could adopt any logic/rules (preferably user configurable) to either warn or reject bundle install with a clear explanation.
That being said, I don't think this should be built-in LiveBundle. I feel this could be a separate project, being used by LiveBundle. I can see this of some uses for other projects to make sure that a bundle that is dynamically retrieved in any way and installed in a binary on the fly, is containing matching native dependencies.
To be explored further.