[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).
show more ...
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 ��