RFC: Support Expo Config Plugins in React Native apps

[TMisiukiewicz]

This RFC introduces the idea of upstreaming part of Expo Config Plugins into the React Native core, which can then be consumed by RN CLI, Expo, and others. We want Config Plugins to become a standard for building and configuring native parts of the apps across the React Native ecosystem.

Rendered RFC can be found here

[pvinis]

I think that's a really good idea. for the longest time I've been thinking/trying to add xcodegen to RN for the app template, so that the upgrades can be simplified. i have not finished it yet, and I'm sad about that, but with this rfc I like the fact that this project generation can be common with expo. prebuild is in my opinion one of the best parts of expo, and the configs on top make it even better, do having those in RN too would be great. I'm all for this 👍.

[brentvatne]

i have lots of thoughts about this, but i think the highest order bit is: what is the issue with using the expo package and using npx expo prebuild if you want to use this functionality? ie: why does it need to be rebranded and forked, with effort in many ways duplicated, in order to avoid using that package and cli command? i could point to a bunch of other concerns i have with the proposal but i think before we get into any weeds here this is an important one for us to figure out.

• you can use it in projects created with npx react-native init, see: https://docs.expo.dev/guides/adopting-prebuild/
• support for out of tree platforms means opening up the --platform flag for prebuild, and otherwise building out support for it would be the same as it would be if this were part of the react-native community cli. we merged a PR that supports this in feature(cli): improve prebuild for arbitrary template platforms expo/expo#22201. here's an example of using expo prebuild to output a macos project: https://github.com/byCedric/custom-prebuild-example

[TMisiukiewicz]

Hi @brentvatne, thanks for your comment. Adding Expo to an existing project is an obvious alternative that I didn’t include in the RFC, thanks for pointing that out, will add it soon.

Expo prebuild works in majority of cases. However, it generates native code with RN version that depends on Expo release cycle. I think it is a very good solution, but we were thinking more of something that could go beyond that. I see a big potential in the --template flag which allows to work with different versions, played around with it a little bit and it seems like something that could be very beneficial in achieving that. However, as I can see in the Expo docs, it’s not generally recommended because the modifiers make some undocumented assumptions about the template files. I’m not very much into the technical details of it at this moment, but perhaps making a strict connection between any template and config plugins would reduce possibility of having any issues in this case. Are there any other drawbacks of using --template flag that you are aware of? I think it would also be potentially beneficial in terms of testing RC versions, as it would be easier to adopt by wider audience and collect more early feedback from users testing it in complex apps.

I’m really excited about opening up the --platform flag, seems to address out of tree platforms problem perfectly 👍 Great job on that one, we weren’t aware of that!

We’re also trying to discover how does this RFC relates to more advanced setups, like using alternative bundlers or brownfield development. I will try to keep everyone up to date with that once we have any outcome.

Our main goal here is to end up with a great upgrading experience for vast majority of RN users. We’re open to any kind of feedback, and even if our proposal turns out to be wrong, it’s a great opportunity to get all the parties involved and decide which way to go from there.

[shamilovtim]

Reminds me of the the old days of Cordova. Both platforms could be spun up& down easily by running cordova add ios or cordova remove ios and you'd end up with the same native project including customizations. Customizations were stored in XML files and most breaking changes were just to those XML files.

[michalchudziak]

I love the proposal. It is a very convenient way to facilitate the update process, which is one of the most commonly reported pain points of working with the framework. Nevertheless, I would like to know about the hybrid/brownfield app perspective. If I understand it well, in such a case, you will most likely need to opt-out of using the plugin system/config generation. To be more specific, I'd like to find answers to the following questions:

• How would the process of integrating RN into existing native apps change?
• How easy would it be to add native screens directly to the app (without using the native module system)?
• What would happen if we run the prebuild command when the ios/android folders already exist? Will they be overridden? Is there any way to prevent that?
• Is there a convenient way to merge already existing manifest/plist file with app.json configuration?

[blakef]

The RFC has been incredibly valuable for driving a lot of discussion between Meta, Callstack and Expo that wouldn’t have occurred without this work. We were fortunate to attend App.js and discuss the implications of this proposal with everyone in person. Our position is that this is a framework concern and not something the React Native platform should be dealing with. We’re going to publish a post about where we see the boundaries between platforms and frameworks.

Expo prebuilds is an excellent solution for many developers who want to build applications with React Native. A large number of developers don’t have a need for an Android or iOS project folder and benefit from only generating these files at build time. Expo have done great work here to simplify this for their framework. The feedback from Brent is correct, developers can use prebuilds for non-Expo projects and they’ve provided docs with those details. We recommend people explore using this approach if it’s viable for their specific needs.

Stepping back from the concrete proposal in the RFC, there’s still a lot of value for fleshing this out as a framework contribution (possibly with supporting changes in the platform). React Native brownfield applications don’t have good solutions for upgrading their extensions in lockstep with React Native. We’ve received a lot of feedback from larger enterprise teams to this effect. Specifically teams that are unable to move large mobile applications completely to a framework like Expo. We would be very interested to see how far an approach that fits well with these types of projects can go. Ideally it’d be easy to upstream back into any React Native framework’s tooling. This is a hard problem which is complimentary to existing framework solutions to the “upgrade problems” of React Native.

[TMisiukiewicz]

Hi @michalchudziak @blakef, thanks for your feedback. Happy the RFC brought some discussion around.

I think the brownfield is an in interesting one. I can see some potential in utilizing already existing mods to automate some steps described in Integration with Existing Apps and when upgrading RN. The main problems I see here are:

• many times brownfield apps don’t follow the RN template structure which makes it harder to apply mods
• upgrading RN requires better understanding what changes are made in the RN template and how to correctly apply them into brownfield app
• Afaik there is no good way of parsing .kts files at this moment
• very common problem when upgrading brownfield apps, mostly on Android, are 3rd-party dependencies

If possible, we could try building some additional config around it to handle more complicated cases. Additionally it could help developers easily handle any conflicts e.g. mismatching dependencies versions etc. Would love to hear more about problems the teams are facing with brownfield upgrade process to have a better understanding of this area

[TMisiukiewicz]

@blakef since the #759 has already been merged, can we close this one? I think RFC for React Native Frameworks has set clear boundaries and it's result satisfies everyone's needs 👍