Conversation
…#44584) # Why Related PR: #44243 On Android 12-13 (API 31-33), there's a platform bug where the splash screen exit animation listener can fire after the activity has stopped, causing a `SurfaceControl.checkNotReleased` crash. This is a known Android issue: https://issuetracker.google.com/issues/242118185 # How - Added an `ActivityLifecycleCallbacks` that cancels the splash screen exit animation when the activity stops on API 31-33, preventing the crash from occurring #### Why not simply remove `setOnExitAnimationListener`? Removing the listener entirely would fix the crash but introduce two regressions: 1. **Forced system fade**: without the listener, the system uses its own default fade to dismiss the splash. Users who set `fade: false` (e.g. to animate individual splash screen parts) would see an unwanted fade regardless. 2. **System bars race condition**: inside the listener, we call `(splashScreenView as SplashScreenView).remove()` instead of `splashScreenViewProvider.remove()` on API >= 31 to avoid triggering `applyThemesSystemBarAppearance`, which races with React Native / Expo system bar appearance management. Skipping the listener would re-introduces this issue on Android 12-13. **This is a mitigation, not a total fix.** The underlying bug is in the Android platform itself and cannot be fully fixed on our side. This change reduces the window in which the crash can occur by cancelling the animation on activity stop, but edge cases with very tight timing may still slip through. It should reduce error occurrences, allowing remaining rare reports to be safely ignored. # Test Plan Tested on Android 12-13 devices by rapidly backgrounding the app during splash screen animation. # Checklist - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
# Summary Resolves #44580 See: https://github.com/kitten/lan-network/blob/main/CHANGELOG.md#021 # Test Plan - CI should pass unchanged # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
# Why Small QoL improvement. When users post the output from `--verbose`, I'd love to see whether they've actually run the latest version, just in case the latest isn't resolved or a cached version is used. This makes the output a little more trustworthy and reliable in the future. # How - Add `expo-doctor: v0.0.0` output to `--verbose` # Test Plan - Run `expo-doctor`; NOTE: There's a build error right now that'll need to be resolved first # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
# Summary See: https://github.com/kitten/fetch-nodeshim/blob/main/CHANGELOG.md#0410 # Test Plan - CI should pass unchanged # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
# Why `@expo/cli`'s internal files aren't meant to be re-used. On `main`, this is now resulting in a build error since the `package.json:exports` don't allow this file to be reused. Since this was always meant to be a separate implementation, this PR adds a vendored API call for the native modules JSON. # How - Add `src/api/getNativeModuleVersionsAsync.ts` with slim native modules fetching - Replace internal `@expo/cli` import path with it # Test Plan - CI should pass unchanged / manual run validates this # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
# Why We must upgrade `react-native-reanimated` to version `4.3.0` to properly support react-native `0.85.0` # How - Bump `react-native-reanimated` to `4.3.0` - Bump `react-native-worklets` to `0.8.1` # Test Plan - BareExpo # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [ ] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…3926) # Why I was checking if any improvements can be made to the non-interactive mode in `create-expo-module`. I didn't really find much, I added some tests though. # How Check for `EXPO_NONINTERACTIVE` just in case, add a few detection tests to non-interactive mode.`ci === 'true' || ci?.toLowerCase() === 'true'` can be simplified to ` ci?.toLowerCase() === 'true' ` # Test Plan Tested on MacOS by running `yarn test:e2e`
# Summary Resolves #44097 See: https://github.com/kitten/dnssd-advertise/blob/main/CHANGELOG.md#114 # Test Plan - CI should pass unchanged # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…ndle (#44559) # Why This adds feature parity to iOS for the `mode` parameter when opening a file handle. A specific use-case I intend to use this for is reading files returned from `expo-media-library` that the app doesn't have permission to open with write access. # How The change uses the same general design as #42983 and the built-in methods on Foundation's `FileHandle` to implement the behavior of each `FileMode`. https://developer.apple.com/documentation/foundation/filehandle # Test Plan The `FileMode` tests written for #42983 now run for both iOS and Android. # Checklist - [X] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) --------- Co-authored-by: Expo Bot <34669131+expo-bot@users.noreply.github.com>
…#44591) # Summary Resolves #44578 Related #41714 (changed new option on `transformer`) The option doesn't exist on `watcher` anymore, as far as I'm aware and should be removed # Test Plan - CI should pass unchanged # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…tently (#44414) # Why Contains/Supersedes #40563 Resolves #39738 Resolves #40837 The paths passed to `mainModuleName` have many different code paths in which they're being resolved that are inconsistent and lead to subtle bugs, since some are missing the fix-ups of others. The `--entry-file` argument in React Native is generally passed as an absolute path. However, `resolveAppEntry`, expo-updates' manifest scripts, and other invocations may pass a relative path. This path is generally considered to be relative to the **project root**. The CLI sometimes interprets this as a relative path to the server root, since that's what the output for `entryFile -> mainModuleName` has to be converted to. This leads to confusing situations where, often specifically on Windows, where React Native passes a relative path by default, the resulting `mainModuleName` is incorrect when the server root differs from the project root (monorepos) # How - Remove duplicate relative entrypoint conversions and duplicate `mainModuleName` resolution implementations - Update implementation in `@expo/config/paths` to handle relative paths (relative to `projectRoot`) and to convert to posix paths The exports that are re-used from `@expo/config/paths` have been marked as deprecated since they're now internal and may be moved to `@expo/cli`. Other duplicate helpers in `@expo/cli` have already been deleted but we might want to do another pass on this. # Test Plan - We expect all tests to pass unaltered - **Exception:** Our own CLI E2E embed tests pass an entry relative to the server root, and have been altered since this is now expected to fail Some care will have to be taken when backporting this, since: - `expo/scripts/resolveAppEntry` has been altered - `expo-updates` has been altered but version can be misaligned - **Note:** There's a re-export in `@expo/cli` that tries to smooth over the inaccurate relative path that the old version passes # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) --------- Co-authored-by: Cedric van Putten <github@cedric.dev>
…ng a module (#43899) # Why Currently `create-expo-module` always creates modules for all platforms # How Add `--platform` option to specify platforms supported by the module - For local modules the creator pre-selects platforms defined in `app.json` for the prompt - For non local modules the creator defaults to all platforms when unspecified - In non-interactive mode the local module will be created for all platforms when `--platform` is not provided - Added tests # Test Plan Tested by creating a bunch of modules on MacOS, and by running the added e2e tests
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )