[Feature Request] Support for Expo Config Plugins

[leggomuhgreggo]

I am on a team that's fixin to start work on a cross-platform Expo app, intended to replace our three legacy clients. Wanted to inquire whether y'all would consider adding support for Config Plugins, so this library can be used with the Expo Managed Workflow (i.e. without ejecting)

Thanks for your consideration!

Feature Context

Over the past several months Expo has introduced features which enable apps to use external native modules, without ejecting Expo's managed workflow.

The customizations to the iOS and Android code that are required by a given native module are automated, using an AST-based API that Expo provides through "Config Plugins" feature.

These automations (called "mods") are executed during a new "Prebuild" phase, in which boilerplate ios and android directories are created — and then their respective files are altered, based on the instructions in a given modules config plugin. The end result is essentially the same as if you ejected and manually changed the ios/android files.

Here's the Expo blog post announcing Config Plugins and the associated feature-set.

Overview of Proposed Implementation

The process for creating a Config Plugin is detailed here:
https://docs.expo.io/guides/config-plugins/#creating-a-plugin

There are a few different "recipes" for how to implement — but the gist of it is:

• Create the app.plugin.js file, at the project root — which serves as a standard entrypoint where expo can resolve the plugin code. [ex: expo-camera]
• Export a function prefixed using "with" (eg withFeature) which accepts a config object that can be used, along with @expo/config-plugins methods, to implement mods for each platform's native code. [ex: withCamera]
• Add mods corresponding to the setup steps in your README.md
• Celebrate!

Additional Question

Are there specific feature in the RN SDK, that aren't supported in the standard React SDK? I've been trying to parse the docs a little bit but it's not totally clear to me. Thanks!

[louis-launchdarkly]

Hello @leggomuhgreggo, thank you for the feature request! While we are currently focusing on fixing some of the issues reported for React Native, we will discuss this and give you an update afterward.

[leggomuhgreggo]

Thanks @louis-launchdarkly

I wonder if, in the mean time, you might be able to offer clarification on the question:

Are there specific feature in the RN SDK, that aren't supported in the standard React SDK? I've been trying to parse the docs a little bit but it's not totally clear to me.

🙏

[louis-launchdarkly]

Hello @leggomuhgreggo, that is a good question - based on the documentation React Native and JavaScript for React, the key difference that is supported in React Native but not React are mobile specific features. The two that I know of are Monitor SDK Status and Offline Mode

[yvan33]

@louis-launchdarkly - Any update on this? We also need this in my team.
Ejecting from the Expo managed workflow is not an easy move and not preferable for us.

[erisvaldojunior]

Any news on this?

[louis-launchdarkly]

Hello @yvan33 and @erisvaldojunior, thank you for checking. Unfortunately, we are not getting to this yet, and this is still an open enhancement request in the backlog.

I should have asked earlier - is there anyone interested in making a contribution to implement this? Engineers who are familiar with the Expo will likely implement this better than us, who are not familiar with the Expo framework.

[ridafkih]

@louis-launchdarkly I got it.

Update, judging by the lack of native configuration (just Podfile) in the installation instructions on LaunchDarkly, I'm unsure if this would even require a configuration plugin at all. In contrast, when I created the ridafkih/expo-fullstory there were configuration accommodations I had to make for various .gradle files, Podfile, and in the Info.plist, which warranted the usage of an Expo Config Plugin. I created and leveraged the usage of a module I made called ridafkih/prybar in order to modify these files during the build.

In this case, since the configuration happens at runtime, there should be no problem simply installing and building your client with EAS.

In short, this would mean that for Expo users, the installation would be similar to any other non-native configured package.

Installation Steps

1. Add LaunchDarkly's SDK package with expo add launchdarkly-react-native-client-sdk
2. Build your application using EAS Build
   • For example, eas build --profile development --local
3. Profit?

At that point, you should be able to use LaunchDarkly's SDK like normal.

TL;DR

Part of EAS builds' build steps is installing Cocoapods, so installing the module using expo add launchdarkly-react-native-client-sdk and then building the client using EAS Build is enough, since none of the native files have to be modified, there is no need for any sort of Expo build configuration plugins.

If there's something I'm missing, I implore anyone here to let me know and I can create a configuration plugin to accommodate those needs. @erisvaldojunior @yvan33 @leggomuhgreggo