[expo-manifests] Fix error in handling nested array (#23562)# Why Fix crash on iOS if a plugin is passed in as an array, but with only the name element and not the props element. Also fix co
[expo-manifests] Fix error in handling nested array (#23562)# Why Fix crash on iOS if a plugin is passed in as an array, but with only the name element and not the props element. Also fix corresponding code on Android, where an exception is thrown. Fixes #23549. # How Modified `Manifest.swift` and `Manifest.kt` to handle the above case correctly. # Test Plan - Tested with Expo Go and the project provided in the above issue - New unit tests for both iOS and Android # Checklist - [x] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [x] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [x] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin).
show more ...
[file-system][ios] Add UTF-8 URI support (#21196)# Why Closes https://github.com/expo/expo/issues/10476 # How This PR updates all iOS local uri instances (NSURL) to parse them using percent
[file-system][ios] Add UTF-8 URI support (#21196)# Why Closes https://github.com/expo/expo/issues/10476 # How This PR updates all iOS local uri instances (NSURL) to parse them using percent-encoded characters when necessary, that way we're able to support paths like `fs.documentDirectory + "中文"`. The main difference from https://github.com/expo/expo/pull/21098 is that this PR uses a similar approach to https://github.com/expo/expo/pull/21139, where we first decode the input URI to ensure we don't double-encode it. It also uses `stringByAddingPercentEncodingWithAllowedCharacters:[NSCharacterSet URLPathAllowedCharacterSet]` instead of `fileURLWithPath` and keeps the original scheme in place. # Test Plan Added unit test support to the EXFileSystem module, just testing `percentEncodeURIStringAfterScheme` for now, and updated `apps/test-suite/tests/FileSystem.js` to include a `Create UTF-8 uri` test. https://user-images.githubusercontent.com/11707729/217058407-3ff04176-2b72-43f9-803c-6a097f0a79ee.mov # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [x] 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 `expo prebuild` & EAS Build (eg: updated a module plugin).
Update Podfile locks and fix ExpoModulesCore podspec for Fabric [skip ci]
[ios] Bump deployment target to 13.0 (#18873)
Fix unquoted $NODE_BINARY inside xcode shell scripts (#18727)# Why If a user has a a NODE_BINARY with a space like for ex: `/Users/johndoe/Library/Application Support/fnm/node-versions/v16.16.0/
Fix unquoted $NODE_BINARY inside xcode shell scripts (#18727)# Why If a user has a a NODE_BINARY with a space like for ex: `/Users/johndoe/Library/Application Support/fnm/node-versions/v16.16.0/installation/bin/node`, Xcode woudl then fail to run node because of the missing double quotes. Xcode build error: ``` …/Script-00DD1BFF1BD5951E006B06BC.sh: line 15: /Users/johndoe/Library/Application: No such file or directory Command PhaseScriptExecution failed with a nonzero exit code ``` # How All other shell scripts inside Xcode use `"` with env var so did the same for the `$NODE_BINARY` # Test Plan ``` npx create-expo-app@latest -t expo-template-blank-typescript@46 shiny cd shiny yarn expo install expo-dev-client yarn expo run:ios (you will get a build failure if you have a space in your node path, for example setup node with `fnm`) (I then manually changed the project.pbxproj with the changes from this PR) yarn expo run:ios (no build failure) ```
Deprecate source-login-scripts.sh (#18330)# Why the `source-login-scripts.sh` introduced a lot of pain where the community reported much build errors from it. it doesn't support shells other tha
Deprecate source-login-scripts.sh (#18330)# Why the `source-login-scripts.sh` introduced a lot of pain where the community reported much build errors from it. it doesn't support shells other than zsh and bash. this pr find a new way to deal with xcode building issues that it cannot find the correct nodejs path. close ENG-4864 close ENG-5242 # How react-native introduces `.xcode.env` and `.xcode.env.local` for developers to override the `$NODE_BINARY`: https://github.com/facebook/react-native/pull/33546 to make sure building success from expo-constants, expo-updates, and also the app target when generating bundles. i would like to reuse the `.xcode.env` and `.xcode.env.local` from react-native. this pr further generates `.xcode.env.local` automatically for the app during `pod install`. we can ensure that `pod install` is executed from shell and nodejs is available. so we will generate `export NODE_BINARY="$(command -v node)"` in the `.xcode.env.local`. for xcode, the path will be `$PODS_ROOT/../.xcode.env.local`, every xcode subprojects can source the file to get correct `$NODE_BINARY`. # Test Plan - building bare-expo from xcode (opening xcode by macos finder) - building bare-expo by `yarn ios` - updates e2e ci passed - building expo-go (prerequisite: #18344) Co-authored-by: James Ide <[email protected]>
[dev-menu] Update `react-native-reanimated` to `2.9.1` (#18182)# Why Closes ENG-5411. Closes ENG-5685. # How Run: ``` et vendor -c "[dev-menu] reanimated" ``` and adjust the vendoring
[dev-menu] Update `react-native-reanimated` to `2.9.1` (#18182)# Why Closes ENG-5411. Closes ENG-5685. # How Run: ``` et vendor -c "[dev-menu] reanimated" ``` and adjust the vendoring script. # Test Plan - bare-expo with NCL ✅ - bare-expo with sandbox ✅
Add expo-clipboard to test xcscheme
[ios][tools][ci] Redesign iOS unit tests (#17634)# Why iOS Unit Test CI job had several issues: - Fastlane is being run for each package separately, so it's restarting the simulator each time.
[ios][tools][ci] Redesign iOS unit tests (#17634)# Why iOS Unit Test CI job had several issues: - Fastlane is being run for each package separately, so it's restarting the simulator each time. This makes the job slower and moreover, test results are scattered across all fastlane logs. - Some tests are being run on bare-expo, others on the client project. - Packages to be tested need to be defined manually in podfile - Some dev-client tests aren't being run at all (bug in expotools) # How Basically, running tests once from a single xcscheme is faster and clearer than doing it separately for each package. - Applied some autolinking + fastlane changes from #16993 and https://github.com/expo/expo/commit/0e0c1e3db71535002e56453ff6004b06e2836c8e - now we have `use_expo_modules_tests!` for autolinking only test packages. - Created (`expo init -t bare`) a new `apps/native-tests` app which has no JS code, but only native iOS project with a single test-only scheme (`NativeTests.xcscheme`) > It might be possible to integrate it as a separate test target in bare-expo instead of creating a new app - Created a custom fastlane action `generate_test_scheme`, which takes that NativeTests scheme as a template and automatically finds test targets (named `PodspecName-Unit-Tests`, generated by CocoaPods during `pod install`) and generates a `NativeTests_generated` scheme aggregating all these targets. Package filtering is also supported. - Created a new ios lane `:unit_tests` which uses that action to generate the scheme and then run tests, adopted the `et ios-native-unit-tests` command to use this lane. - Fixed expotools not recognizing the `expo-dev-launcher` podspec, because it was in the package root instead of the `ios/` subdir. - Got rid of `React-hermes` test spec dependencies. They're not needed anymore. JS engine for `apps/native-tests` is set to JSC. - Added `FASTLANE_SKIP_UPDATE_CHECK=1` to the CI env to prevent fastlane from spamming. One drawback of this approach is that we now have to maintain another app, another podfile etc