[autolinking] Introduce gradle plugin autolinking (#21377)# Why for #21327 because it introduces a gradle plugin inside expo-dev-launcher # How add android gradle plugin autolinking suppor
[autolinking] Introduce gradle plugin autolinking (#21377)# Why for #21327 because it introduces a gradle plugin inside expo-dev-launcher # How add android gradle plugin autolinking support. ~for security reasons, currently only support expo-dev-launcher.~ updates: we will have a highlighted log: # Test Plan ci passed
show more ...
[autolinking] Fix debug only modules weren't installed if the `DEBUG` flag wasn't present in `OTHER_SWIFT_FLAGS` (#17383)# Why Fixes https://github.com/expo/expo/issues/17373. Follow up https:/
[autolinking] Fix debug only modules weren't installed if the `DEBUG` flag wasn't present in `OTHER_SWIFT_FLAGS` (#17383)# Why Fixes https://github.com/expo/expo/issues/17373. Follow up https://github.com/expo/expo/pull/17378. # How Use the `EXPO_CONFIGURATION_DEBUG` flag instead of `DEBUG`. # Test Plan - bare-expo ✅ - a new project with SDK 45 ✅ (both projects were tested in debug and release configuration)
[autolinking][ios] Add support for debug only modules (#17331)# Why Needed to close https://github.com/expo/expo/issues/17246. # How Adds support for debug only modules. Those modules will
[autolinking][ios] Add support for debug only modules (#17331)# Why Needed to close https://github.com/expo/expo/issues/17246. # How Adds support for debug only modules. Those modules will only be added to the debug configuration. - Added a `debugOnly` field in the `iOS` section in the `expo-modules-config.json` - Ensured that debug modules are wrapped using the `#if DEBUG` directive inside of the ExpoModulesProvider # Test Plan - bare-expo ✅ ExpoModulesProvider without `debugOnly` modules: ```swift /** * Automatically generated by expo-modules-autolinking. * * This autogenerated class provides a list of classes of native Expo modules, * but only these that are written in Swift and use the new API for creating Expo modules. */ import ExpoModulesCore import ExpoCellular import ExpoClipboard import ExpoCrypto import EXDevLauncher import EXDevMenu import EASClient import ExpoHaptics import ExpoImageManipulator import ExpoImagePicker import ExpoKeepAwake import ExpoLinearGradient import ExpoLocalization import ExpoRandom import EXScreenOrientation import ExpoSystemUI import EXTrackingTransparency import ExpoWebBrowser @objc(ExpoModulesProvider) public class ExpoModulesProvider: ModulesProvider { public override func getModuleClasses() -> [AnyModule.Type] { return [ CellularModule.self, ClipboardModule.self, CryptoModule.self, EASClientModule.self, HapticsModule.self, ImageManipulatorModule.self, ImagePickerModule.self, KeepAwakeModule.self, LinearGradientModule.self, LocalizationModule.self, RandomModule.self, ExpoSystemUIModule.self, TrackingTransparencyModule.self, WebBrowserModule.self ] } public override func getAppDelegateSubscribers() -> [ExpoAppDelegateSubscriber.Type] { return [ ExpoDevLauncherAppDelegateSubscriber.self, ScreenOrientationAppDelegate.self ] } public override func getReactDelegateHandlers() -> [ExpoReactDelegateHandlerTupleType] { return [ (packageName: "expo-dev-launcher", handler: ExpoDevLauncherReactDelegateHandler.self), (packageName: "expo-dev-menu", handler: ExpoDevMenuReactDelegateHandler.self), (packageName: "expo-screen-orientation", handler: ScreenOrientationReactDelegateHandler.self) ] } } ``` ExpoModulesProvider with two `debugOnly` modules: ```swift /** * Automatically generated by expo-modules-autolinking. * * This autogenerated class provides a list of classes of native Expo modules, * but only these that are written in Swift and use the new API for creating Expo modules. */ import ExpoModulesCore import ExpoCellular import ExpoClipboard import ExpoCrypto import EASClient import ExpoHaptics import ExpoImageManipulator import ExpoImagePicker import ExpoKeepAwake import ExpoLinearGradient import ExpoLocalization import ExpoRandom import EXScreenOrientation import ExpoSystemUI import EXTrackingTransparency import ExpoWebBrowser #if DEBUG import EXDevLauncher import EXDevMenu #endif @objc(ExpoModulesProvider) public class ExpoModulesProvider: ModulesProvider { public override func getModuleClasses() -> [AnyModule.Type] { return [ CellularModule.self, ClipboardModule.self, CryptoModule.self, EASClientModule.self, HapticsModule.self, ImageManipulatorModule.self, ImagePickerModule.self, KeepAwakeModule.self, LinearGradientModule.self, LocalizationModule.self, RandomModule.self, ExpoSystemUIModule.self, TrackingTransparencyModule.self, WebBrowserModule.self ] } public override func getAppDelegateSubscribers() -> [ExpoAppDelegateSubscriber.Type] { #if DEBUG return [ ScreenOrientationAppDelegate.self, ExpoDevLauncherAppDelegateSubscriber.self ] #else return [ ScreenOrientationAppDelegate.self ] #endif } public override func getReactDelegateHandlers() -> [ExpoReactDelegateHandlerTupleType] { #if DEBUG return [ (packageName: "expo-screen-orientation", handler: ScreenOrientationReactDelegateHandler.self), (packageName: "expo-dev-launcher", handler: ExpoDevLauncherReactDelegateHandler.self), (packageName: "expo-dev-menu", handler: ExpoDevMenuReactDelegateHandler.self) ] #else return [ (packageName: "expo-screen-orientation", handler: ScreenOrientationReactDelegateHandler.self) ] #endif } } ```
[autolinking] Support multiple podspecs and gradle projects in a package (#16511)# Why - support the case where a package has multiple podspecs, e.g. [react-native-maps](https://github.com/reac
[autolinking] Support multiple podspecs and gradle projects in a package (#16511)# Why - support the case where a package has multiple podspecs, e.g. [react-native-maps](https://github.com/react-native-maps/react-native-maps/blob/master/docs/installation.md#enabling-google-maps) - being less intrusive to 3rd party libraries when we proposing expo integration. for example, current integration to [reanimated add one line to existing code](https://github.com/software-mansion/react-native-reanimated/blob/a870aa28092322b627695f8cf2ea0dce4db34a53/android-npm/build.gradle#L111) and [turn reanimated gradle project to a different form](https://github.com/software-mansion/react-native-reanimated/blob/a870aa28092322b627695f8cf2ea0dce4db34a53/android-npm/expo/linking.gradle#L15-L45). - expo reanimated integration had introduced some issues as following. based on this, i think we should have a dedicated gradle project. - https://github.com/software-mansion/react-native-reanimated/issues/2711 - https://github.com/software-mansion/react-native-reanimated/pull/2713#issuecomment-1024341773 # How - support multiple podspec linking - `*/*.podspec` - support multiple build.gradle linking - `*/build.gradle` - ~introduce special expo adapter integration where we can put all stuffs including `expo-module.config.json` in `expo/` folder in this case, rn-cli's autolinking will link `RNThirdParty.podspec` and `android/build.gradle`. expo autolinking will link `RNThirdPartyExpoAdapter.podspec` and `expo/android/build.gradle`~ - add expo-module.config.js `android.gradlePath` support to specify custom gradle file paths. # Test Plan ## Unit Tests ``` PASS src/platforms/__tests__/android-test.ts resolveModuleAsync ✓ should resolve android/build.gradle (2 ms) ✓ should resolve multiple gradle files (1 ms) convertPackageNameToProjectName ✓ should strip invalid characters (1 ms) ✓ should convert scoped package name to dash ✓ should have differentiated name for multiple projects ✓ should support expo adapter name PASS src/autolinking/__tests__/findModules-test.ts findModulesAsync ✓ should link top level package (2 ms) ✓ should link scoped level package (1 ms) PASS src/platforms/__tests__/ios-test.ts resolveModuleAsync ✓ should resolve podspec in ios/ folder ✓ should resolve multiple podspecs (1 ms) ``` ## Integration Tests - create extra `ios2/EXApplication2.podspec` in expo-application - create extra `android2/build.gradle` in expo-application - check rn-cli autolinking and expo autolinking co-existence compatibility - move `use_native_modules!` before `use_expo_modules!` in Podfile - create extra `ios2/RNReanimated2.podspec` in reanimated and check whether it's linked. Co-authored-by: Tomasz Sapeta <[email protected]>
[expo-modules-autolinking] add ios.swiftModuleName to expo-module config (#16260)
[autolinking] Rename "modulesClassNames" to "modules" (#15852)
[autolinking] Add `podspecPath` option to config (#15578)# Why A better implementation of https://github.com/expo/expo/pull/15564. # How We don't want to link an RN module that has an `exp
[autolinking] Add `podspecPath` option to config (#15578)# Why A better implementation of https://github.com/expo/expo/pull/15564. # How We don't want to link an RN module that has an `expo-module.config.json` like `reanimated`. That's why we can't just extend a search region. So I've added a new option to the `expo-module config` that indicates where the podspec is located. # Test Plan - run `node --eval "require('expo-modules-autolinking')(process.argv.slice(1))" -- resolve --platform ios` and check if the podspec path changes.
[core] Introduce iOS ReactDelegate for React related instances creation (#15138)# Why original modularized AppDelegateWrapper isn't ideal for expo-updates. we had some bad side effect, e.g. doub
[core] Introduce iOS ReactDelegate for React related instances creation (#15138)# Why original modularized AppDelegateWrapper isn't ideal for expo-updates. we had some bad side effect, e.g. double bridge creation on startup. close ENG-2299 # How ## For module authors introduce `EXReactDelegate` dedicated for react related instances creation. so far we covered: - RCTBridge - RCTRootView - RootViewController (for expo-screen-orientation) if a module wants to handle these creation, there's 2 steps: 1. add `reactDelegateHandlers` in `expo-module.config.json`, e.g. ``` "ios": { "reactDelegateHandlers": ["ScreenOrientationReactDelegateHandler"] } ``` 2. create `EXReactDelegateHandler` derived swift class, e.g. ```swift // ScreenOrientationReactDelegateHandler.swift public class ScreenOrientationReactDelegateHandler: ExpoReactDelegateHandler { public override func createRootViewController(reactDelegate: ExpoReactDelegate) -> UIViewController? { return EXScreenOrientationViewController() } } ``` since the order of whom to create the instance did matter, we also introduce `ModulePriorities.swift` similar to what we did on android. ## For app developers the change to template is minimal, so codemod by `npx install-expo-modules` is also feasible. ```diff - RCTBridge *bridge = [[RCTBridge alloc] initWithDelegate:self launchOptions:launchOptions]; - RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge moduleName:@"main" initialProperties:nil]; + RCTBridge *bridge = [self.reactDelegate createBridgeWithDelegate:self launchOptions:launchOptions]; + RCTRootView *rootView = [self.reactDelegate createRootViewWithBridge:bridge moduleName:@"main" initialProperties:nil]; self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds]; - UIViewController *rootViewController = [UIViewController new]; + UIViewController *rootViewController = [self.reactDelegate createRootViewController]; ```
[core] Enhance RN wrapper for 3rd-party libraries integration (#14883)# Why Enhance `ReactNativeHostWrapper` and `ReactActivityDelegateWrapper` for expo-updates error recovery and 3rd-party libr
[core] Enhance RN wrapper for 3rd-party libraries integration (#14883)# Why Enhance `ReactNativeHostWrapper` and `ReactActivityDelegateWrapper` for expo-updates error recovery and 3rd-party libraries integration # How - introduce internal ModulePriorities to define modules listeners/handlers order like iOS did - autolinking android searches source code other than `src/**/*Package.{java,kt}` - add `onWillCreateReactInstanceManager` and `onDidCreateReactInstanceManager` - deprecate previous `createReactInstanceManager` loop to all packages (replace with `onBeforeCreateReactInstanceManager`) - support `createRootView` for react-native-gesture-handler
[ios] New ExpoAppDelegate independent of singleton modules (#14867)
[sweet-api][kotlin] Foundation of the sweet api on Android (#14778)# Why A follow up to the https://github.com/expo/expo/pull/13272 # How - Changed the auto-linking script to generate a li
[sweet-api][kotlin] Foundation of the sweet api on Android (#14778)# Why A follow up to the https://github.com/expo/expo/pull/13272 # How - Changed the auto-linking script to generate a list of modules using the new API. - Added new abstraction over the old module registry. - Created a DSL API (not finished, but the final version should look very similar to the current state). - Integrate the new abstraction with the old `NativeModuleProxy`. # Current version In the current version you can: - export constants - export methods - method arguments are cast from the dynamic to the type expected by method implementation - module definition is static - that will be changed in the future > Note: The way, I convert types is not final. It'll be changed. The current implementation is more POC than the final product. # Test Plan - unit tests ✅ - rewritten one module to use the new API - not included in that PR ✅
[autolinking] Generate Swift modules provider in all projects (#14384)
Make expo package linkable by RN instead of expo-modules-core (#14277)
[eslint-config] remove `arrowParens` overwrite, reformat files (#14232)
[autolinking][android] Fix `org.unimodules.BasePackage` cannot be cast to `Package` (#14122)# Why Fixes `org.unimodules.BasePackage` cannot be cast to `Package`. # How - Made sure that `ex
[autolinking][android] Fix `org.unimodules.BasePackage` cannot be cast to `Package` (#14122)# Why Fixes `org.unimodules.BasePackage` cannot be cast to `Package`. # How - Made sure that `expo-modules-autolinking` will link only modules that extend `expo.modules.core.BasePackage`. - Added a flag to import modules that extends `org.unimodules.core.BasePackage`. Only for test purposes. Can be removed after the next SDK release. We may want to add a mechanism to auto-detect from which namespace we should use `Base Package`. Right now you need to have new versions of expo packages to use a new auto-linking script. # Test Plan - https://github.com/byCedric/expo-modules-bare-42 ✅ - e2e tests ✅
[autolinking] Add e2e tests (#13892)# Why Added e2e tests to `expo-modules-autolinking`. # How - Tested using https://github.com/byCedric/eas-monorepo-example monorepo. - Added backward
[autolinking] Add e2e tests (#13892)# Why Added e2e tests to `expo-modules-autolinking`. # How - Tested using https://github.com/byCedric/eas-monorepo-example monorepo. - Added backward compatibility - make sure that `org.unimodules.interface.BasePackage` is also linked by the new autolikning. - Used different imports in `Git.ts` - otherwise, clone repo doesn't work ����♂️
[expo-modules] Move code from `unimodules` into `expo-modules-core` (#13703)# Why Migrated `unimodules-core`, `unimodules-react-native-adapter`, `unimodules-app-loader` into `expo-modules-core`
[expo-modules] Move code from `unimodules` into `expo-modules-core` (#13703)# Why Migrated `unimodules-core`, `unimodules-react-native-adapter`, `unimodules-app-loader` into `expo-modules-core` # How - Change package using AS refactor tools - Fix some places where AS wasn't able to do automatically - Fix compatibility with new auto-linking - Ensure that classes which are used during installation steps are still available in the old place # Test Plan - expo-go (tested using unversioned and 41) - bare-expo
[expo-modules][android] propose module-level app or activity customization support (#13457)# Why Some modules require additional setup into MainApplication or MainActivity, e.g. expo-splash-scre
[expo-modules][android] propose module-level app or activity customization support (#13457)# Why Some modules require additional setup into MainApplication or MainActivity, e.g. expo-splash-screen or react-native-gesture-handler Traditionally, we used pre-shaped templates or regular expression in config plugin. This PR propose a way to make MainApplication and MainActivity extensible. # How Introducing `ApplicationLifecycleListener` and `ReactActivityLifecycleListener` for expo-modules, an expo-module package could register these two listeners. For POC, expo-splash-screen in bare-expo is also migrate to the new model. ### Performance impact Leveraging the auto-linking mechanism, a notable change is that we need expo-modules package list before react-native bootstrap. In theory, the change may take longer time to show splash screen. My measurement from `MainApplication.onCreate` to `SplashScreenViewController.show` Before: 74.2ms After 80.0ms There is no meaningful impact to launch time. # Test Plan bare-expo android app will show splashscreen even removed the `SplashScreen.show` in MainActivity.
[swift] Swiftified expo-tracking-transparency (#13566)
[ios] Foundation of first-class support for native modules written in Swift (#13272)
[autolinking] Generating Swift modules providers on iOS (#13315)
[ios][android] New autolinking implementation in TypeScript (#11593)