Hey folks I know EAS Update is WIP so this might be on the backlog but have you considered automatically handling native vs js version updates for the managed workflows? It seems EAS Build has a pretty solid handle on if the native code has changed or not. I’d love a command that would automatically build or update depending on whether native code changed and then in app either send the user to download the latest in the event of native updates (internal link or app store) or update the js seamlessly as usual if not.
I can build all that around EAS Update mostly and had a very ugly version on expo update using the hash of the yarn.lock as my runtimeVersion but it’d be nice to support something cleaner. The hash solution was not all that precise as changing any package version triggered a new full build. Even an eas or expo command to check changed packages for native modules would likely help there.
I don’t think EAS build has a solid handle at all on whether or not native code has changed. Even the Github Actions hooks that Expo ships has a very crude ‘did any of these files change?’ mechanism for detecting whether you need a full build or not.
For example, there’s packages without any native parts in it, those can be added or removed and don’t require a full build, as it only affects the Javascript bundle. And there’s more examples where it’s not as straightforward. In the end, all the tools can do is be very conservative about it, unless the user tells the tools what’s going on (as in: manually decides between build and publish).
There is almost definitely some analysis on the files involved in the native build that has that information or at least a better stab at it than “any yarn.lock change” or “only expo sdk version changes”
For example, there’s packages without any native parts in it, those can be added or removed and don’t require a full build, as it only affects the Javascript bundle.
So that’s exactly my point. The naive approach of hashing the lock file fails as it revs on every package update even if it’s a js only package.
I could produce a hash using the lock entries for only packages with unimodules defined but that’s non-trivial. That would ensure the version only gets revved if a package that could have updated native code was changed. A significant improvement.
EAS of course can do better because it has direct access to the podfile and gradle file during the native portions which will tell you if unimodules native content has been updated within the build’s transitive closure of dependencies.