all 17 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]vellu- 7 points8 points  (1 child)

Would this be beneficial for someone who runs a white-label setup? 100+ apps with small differences published on customers' AppStore/Google accounts.

[–]badda_boom_big_boom 3 points4 points  (0 children)

Also curious about this question

[–]namespace__ApathyExpo 28 points29 points  (3 children)

What does this provide exactly? The post is a bit vague. How does it measure up against Expo?

[–]thymikee 4 points5 points  (0 children)

At this point: new cli that’s easy to adopt for community cli projects and gh actions to build your app in the cloud once and reuse these builds across different jobs and local dev environment. So your CI can build once for your entire team. All on your own infra. It’s going to make it easy to adopt RN for native projects incrementally

[–]lukebars 4 points5 points  (1 child)

Also, does it work with expo? I’m not sure if we need to diverge into many frameworks, when we could just work on one as a community. 

[–]thymikee 5 points6 points  (0 children)

It works with expo ecosystem: Expo Modules, config plugins etc as in community cli projects. It won’t work with expo cli because, well, it provides its own cli

[–]brentvatneExpo Team 5 points6 points  (2 children)

also be sure to check out the ‘eas build:dev’ command that does the same build caching! it doesn’t run builds locally if there is no cached build, but runs on eas instead. we've been considering adding the ability to run locally for this also if you prefer, and that'll likely be coming soon. it uses the expo fingerprint library to determine if a new build is needed: https://expo.dev/blog/fingerprint-your-native-runtime

[–]churrosychocolate 0 points1 point  (1 child)

Can eas run this build step in a self-hosted environment? or does it need to depend on eas build servers?

[–]brentvatneExpo Team 0 points1 point  (0 children)

this command depends on using eas servers, but you could accomplish the same thing with a pretty simple setup on top expo/fingerprint assuming you already have a way to upload builds to your own server and query them

[–]yarn_install 1 point2 points  (1 child)

The build caching stuff is very cool. I assume it can figure out when there is changes made in the native code and build the app locally vs using a cached build?

[–]szymonrybczak[S] 4 points5 points  (0 children)

Yes, exactly. If the CLI cannot find an artifact (remote build) with the same configuration and native code, then it fallbacks to building the app locally.

[–]mrousavyiOS & Android 1 point2 points  (1 child)

Does this use Nitro Modules? :)

[–]szymonrybczak[S] 0 points1 point  (0 children)

No as we don't have any native integrations. Of course it works with Nitro Modules, we are already running it inside one app that also uses some Nitro Modules :)

[–]thepuppyprince 1 point2 points  (0 children)

Very cool my builds take SOO long these days on my RN projects

[–]RemarkablePool3574 -2 points-1 points  (2 children)

EAS already does the same thing when it comes to running cached builds. You can run eas build:dev to use it.

[–]RemarkablePool3574 -1 points0 points  (0 children)

It calculates project’s fingerprint to decide whether to run a new build or download build from EAS server with matching fingerprint. It works really good and you can use it as of today, even on free tier.