[autolinking] Maintain hierarchical order when linking isolated modules (#24351)# Why My previous fix for isolated modules (https://github.com/expo/expo/pull/23867) is not fully correct. The ol
[autolinking] Maintain hierarchical order when linking isolated modules (#24351)# Why My previous fix for isolated modules (https://github.com/expo/expo/pull/23867) is not fully correct. The old fix basically discovers _every dependency_ within the pnpm store folder. - This works, but might also link modules that are unrelated to the Expo project (e.g. when using monorepos). - It also loses the hierarchical structure, e.g. nested dependencies from `expo` (like `expo-application`) are added as being on the same level as direct project dependencies. # How This new fix attempts to keep these nested dependencies hierarchy as much as possible. Instead of looking up the pnpm store, it tries to detect if isolated modules are used. If it's detected, it looks up every individual "group of isolated modules" by expanding the `searchPaths`. The detection is done by the following check: - If the current "realpath" of the package being linked has a parent `node_modules` folder ... - ... and that `node_modules` folder is not "searched" yet (not added to `searchPaths` yet) ... - add this parent `node_modules` folder to the `searchPaths` to also link dependencies in those folders > ⚠️ This _**should**_ work, without checking on `.pnpm` store name, since linked modules should never have a direct `node_modules` parent. That only happens when using isolated modules. # Test Plan ~~We probably need to add dedicated pnpm tests to autolinking, but for now, it's manually testable with the following steps:~~ Added the two test cases below, as unit tests (lots of mocking). Probably need to add e2e tests and use pnpm too. You can still test it manually with the following steps: - Create a basic Expo project anywhere - `yarn create expo -t tabs ./test-pnpm-autolinking` - `cd ./test-pnpm-autolinking` - Create a dump of autolinking data, to compare it with pnpm - `yarn expo-modules-autolinking resolve --platform android > autolinking-yarn.json` - Reinstall with pnpm - `rm -rf node_modules yarn.lock` - `pnpm install` - Create a new dump of autolinking data, to compare it with yarn - `node <expo/expo>/packages/expo-modules-autolinking/bin/expo-modules-autolinking resolve --platform android > autolinking-pnpm.json` - Check if both `autolinking-yarn.json` and `autolinking-pnpm.json` is identical Then also check what happens if a different version of `expo-application` is installed as project dependency. It should take priority over the `expo > expo-application` version in both pnpm and yarn autolinking. I've used vscode launch for this to also check what exactly is going on inside autolinking. For that, you'll need to add `.vscode/launch.json` to your expo/expo repo, and update the paths. See snippet below: <details><summary><code>.vscode/launch.json</code> file</summary> ```jsonc { "configurations": [ { "type": "node", "request": "launch", "name": "Expo Autolinking: resolve", "program": "${workspaceFolder}/packages/expo-modules-autolinking/bin/expo-modules-autolinking", "args": [ "resolve", "--platform", "android" ], "console": "integratedTerminal", // Update the path below to your Expo project installed with pnpm "cwd": "/Users/cedric/Desktop/test-sdk-50/expo-pnpm" } ] } ``` </details> # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin).
show more ...
[lint] Upgrade to Prettier v3, typescript-eslint to v6 (#23544)Why --- Prettier 3 is out. Add support for it with this linter config. **Note for reviewer:** the first commit is the one with th
[lint] Upgrade to Prettier v3, typescript-eslint to v6 (#23544)Why --- Prettier 3 is out. Add support for it with this linter config. **Note for reviewer:** the first commit is the one with the actual changes. The rest of this PR are changes to get the linter passing (mostly autofix). How --- Update eslint-config-prettier and eslint-plugin-prettier. To address deprecation warnings, also update typescript-eslint/parser and typescript-eslint/eslint-plugin. Because of an update to typescript-eslint/parser, we need to suppress deprecation warnings (documented in a comment). Regenerated test snapshots. Due to the upgraded dependencies, typecasts and optional chaining are now auto-fixable by lint. This converts warnings into autofixes. Test Plan --- `yarn test` in the linter config. Run `expotools check --all --fix-lint --no-build --no-test --no-uniformity-check` to try this config on the whole repo. --------- Co-authored-by: Expo Bot <[email protected]>
[autolinking] Add support for pnpm isolated modules (#23867)# Why This updates auto-linking to support discovering packages installed with `pnpm`, using the default "isolated module" behavior.
[autolinking] Add support for pnpm isolated modules (#23867)# Why This updates auto-linking to support discovering packages installed with `pnpm`, using the default "isolated module" behavior. # How - Updated pattern matching to include `node_modules/.pnpm/<pkg>@<version>/node_modules/<pkg>` paths We could also filter out some of the symlinks with [something similar to this](https://github.com/mrmlnc/fast-glob/issues/302#issuecomment-869200625). But the current duplication handling seems to be able to handle potential duplicates. # Test Plan This fix is extracted from my pnpm tests to try get pnpm working, without any workarounds. See this repo for more info: https://github.com/byCedric/expo-pnpm-tests/tree/main # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). --------- Co-authored-by: Expo Bot <[email protected]>
[build-properties][autolinking] add extraPods and extraMavenRepos (#22785)# Why some third-party libraries require developers to add extra cocoapods or maven dependencies. this pr adds this cust
[build-properties][autolinking] add extraPods and extraMavenRepos (#22785)# Why some third-party libraries require developers to add extra cocoapods or maven dependencies. this pr adds this customization to expo-build-properties. unlike other properties which are processed by the config-plugins, the dependencies are added by expo-modules-autolinking. close ENG-8503 # How - [build-properties] add `android.extraMavenRepos` and `ios.extraPods` configs and validations. - [autolinking] read the expo-build-properties from config and add the dependencies through autolinking - [docs] `et generate-docs-api-data -p expo-build-properties` # Test Plan - ci passed - integration test on bare-expo 1. add the following properties to **apps/bare-expo/app.json** ```json "plugins": [ [ "expo-build-properties", { "android": { "extraMavenRepos": ["https://customers.pspdfkit.com/maven/"] }, "ios": { "extraPods": [ { "name": "Protobuf" } ] } } ] ] ``` 2. add `implementation 'com.pspdfkit:libraries-java:1.4.1'` to **apps/bare-expo/android/app/build.gradle** 2. Run `npx pod-install` and verify whether Protobuf is added to Podfile.lock 3. Run `./gradlew :app:assembleDebug` and see if the pspdfkit artifact is resolved --------- Co-authored-by: Tomasz Sapeta <[email protected]> Co-authored-by: Aman Mittal <[email protected]>
[autolinking] Support direct paths to modules (#17922)See PR description for details. - Made it possible to specify direct module paths in both `searchPaths` and `nativeModulesDir`. - Fixed the
[autolinking] Support direct paths to modules (#17922)See PR description for details. - Made it possible to specify direct module paths in both `searchPaths` and `nativeModulesDir`. - Fixed the `nativeModulesDir` to be always relative to the project root (`package.json`). Previously, it was resolved differently when called from `example/` and differently for `example/ios` dir, so e.g. `pod install` failed to link the custom module.
[autolinking] Fixed an infinite loop when the package.json is placed at the root path (#17440)
[autolinking] add some unit tests for findModules in workspace (#17425)# Why it's not clear how the transitive packages are linked in expo-modules-autolinking # How add some unit tests for
[autolinking] add some unit tests for findModules in workspace (#17425)# Why it's not clear how the transitive packages are linked in expo-modules-autolinking # How add some unit tests for `findModulesAsync`. hopefully to increase test coverage as well as write down use cases we supported. # Test Plan ``` PASS src/autolinking/__tests__/findModules-test.ts findModulesAsync ✓ should link hoisted package in workspace (1 ms) ✓ should not link hoisted package which are not in app project dependencies ✓ should link packages which are in app project transitive dependencies (1 ms) ✓ should not link packages which are not in app project transitive dependencies (1 ms) ✓ should link non-hoisted package first if there are multiple versions ```
[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]>
[autolinking] Fix finding transitive modules (#16419)Co-authored-by: Expo Bot <[email protected]>
[autolinking] Expose methods for use in expo/prebuild-config (#15950)
[autolinking] Restructure package code (#15502)* [autolinking] Restructure code * Fix relative require paths * Apply suggestions from base PR