Conversation
# Why - `@expo/config-plugins` isn't a necessary import; replace with `expo/config-plugins` like the other files - Remove `@expo/config-types` import; `expo/config` should be used - Open up `@expo/ui` dependency range to include patch versions, since we can't guarantee alignment on the user's side # Test Plan - n/a; should build as expected # 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)
…changes (#43451) # Why While the `customOptOutDirectives` are marked as unstable, they're the most reliable and simple way to opt us out of the react-compiler modifications for widget functions. It seems like a low-risk and optimal way to not modify the widget functions, and seems appropriate since they're not meant to be components, instead being just functions that return Swift UI JSX. # How - Add `customOptOutDirectives` override to `react-compiler` Babel plugin options opting out `widget` directive # Test Plan - Unit test checks that the compiler changes don't happen # 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: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
… update `tools` check) (#43456) Resolves #43448 # Why We almost never intend to pin versions, unless some very specific conditions make this safe. In most cases, pins are just unnecessary and lead to unneeded duplicates. In some conditions pins can be unsafe: - when users depend on the same library and the library has singleton state (or transitive, misaligned dependencies with singleton state) - when the dependency is a native module that is likely to get misaligned (without `autolinkingModuleResolution`) - when it's unreasonable or hard for people to match the version range (if it's transitive, it's unknown) - when it's a peer dependency (it's unlikely to easily share peers with pins) That's a non-exhaustive list. For now, a `tools` check is added to prevent most version pins, since it's easy for commands to accidentally add them. # How - Add tools check to prevent most version pinning - Remove pinned `react-navigation` pins in `expo-router` - Rmeove pinned `arg` version in `expo-updates` # Test Plan - CI should pass; Check local `expo-router` project against latest matching ranges (adjust range if needed to `~` or add an upper limit) # 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)
…ckages (#43458) # Why We seem to be aligned on all versions and the pins here are redundant (and shouldn't ever do anything). They used to be necessary because of transitive dependencies and templates being misaligned on purpose, but those aren't misaligned anymore. The main motivation is to be able to catch duplicate issues more easily. The lockfile changes are an easy indicator to spot misaligned versions. Although the templates aren't actively installed in the monorepo, this gives us an extra opportunity to spot issues, if we do have checks and tests that install them in the monorepo in the future. The other motivation is to reduce the maintenance burden of performing `@react-navigation/*` upgrades, since this will then flag duplicates in the lockfile locally while upgrading. # How - Remove `@react-navigation/*` pins # Test Plan - Check lockfile; noop changes # 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)
# Why Brownfield CI is taking a really long time to run on GitHub Action, and people are getting into long macOS runner queues. To avoid this, we should migrate the existing brownfield workflows to EAS # How Results: | Platform | GitHub Actions | EAS | Improvement | |----------|----------------|-----|------------| | Android | 16m 8s (Debug) + 17m 3s (Release) = **33m 11s** | **10m 50s** (Debug + Release) | ~22m 21s faster | | iOS | 48m 33s (Debug) + 41m 21s (Release) = **89m 54s** | **10m 15s** (Debug + Release) | ~79m 39s faster | # Test Plan CI should be green # 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)
…or` checks (#43461) # Why This was never entirely accurate (see comments on reverted conditions in removed code) and is mostly redundant if we let `expo-doctor` include them in the duplicates check (which is more reliable and accurate) We shouldn't need this anymore, and it's a remaining Node.js entrypoint into `expo-router`. > [!WARNING] > This has the side-effect of removing `install --fix` instructions, and instead `expo-doctor` will point out duplicates. This is intended since `expo-router` has direct dependencies on these packages. They shouldn't be auto-fixed in this way. # How - Drop `expo-router/doctor` - Remove `expo-router/doctor` entrypoint in CLI install checks - Add `@react-navigation/native` and `@react-navigation/core` check to `expo-doctor`'s duplicates check instead # Test Plan - Ran `expo-doctor` manually to verify - Ran `expo install --check` # 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 Not a test we intended to keep, that's now causing sporadic failures. The test wasn't intended to be kept since this doesn't represent stable functionality and is for internal usage/testing. # How <!-- How did you build this feature or fix this bug and why? --> # Test Plan <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> # 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)
# Why Ccache is used in both: `test-suite` and `test-suite-brownfield-isolated`. This PR creates a composite action which can be shared between different workflows. # How Adds the `setup-ccache` composite action. # Test Plan Green CI
…es.json` (#43465) # Why Follow-up to #43461 This readds recommended/bundled versions for: - `@react-navigation/native` - ~~`@react-navigation/bottom-tabs`~~ (Note: re-removed, misalignment here seems partially safe) - and; `@react-navigation/native-stack` The motivations around keeping this out of `bundledNativeModules.json` seem to largely be obsolete and `expo-router/doctor` will be dropped. Instead, we should maintain a supported & tested version range of `@react-navigation/native` in `bundledNativeModules.json`. Optimally, this should be bumped upon upgrading by users to ensure that it aligns with `expo-router`'s assumptions. While `expo-router` sticks with a relatively new version, if people explicitly use an older one, they can disable this in the install checks. This will be necessary to add somewhere to ensure that misalignment (without the duplicates check) becomes even less likely, i.e. after `install --fix` no duplicate with `expo-router` should occur. Version range is hence matched to `expo-router` not latest, but kept to `^` to match. This is a trade-off (if people want to stick to older versions of `react-navigation`) which we were more permissive about in the past, but it stops `expo-router` having a "snow-flake" setup in the monorepo, and means we're more protected. Since we typically set recommended versions in `bundledNativeModules.json`, this is fine. # How - Add `@react-navigation/native` to `bundledNativeModules.json` # Test Plan - Locally tested and version used in `expo/expo` # 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)
…asyncRoutes: true` in SSR (#43446) # Why When serving an SSR-exported app with `asyncRoutes: true` and `unstable_useServerRendering: true`, the browser throws `__d is not defined` because JavaScript assets in `routes.json` are not added in the correct order. Additionally all async chunks are loaded for every page, defeating the purpose of enabling `asyncRoutes`. # How In `@expo/cli`, JavaScript artifacts are now separated into sync and async chunks during export. Sync chunks are written to the top-level `assets.js` in the server manifest. Async chunks are matched to their respective HTML routes, and are written to a new per-route `assets` field for each `htmlRoute` in the server manifest. In `expo-server`, the top-level and per-route assets are merged (top-level first) and passed along to the SSR rendering module (`getStaticContent()`), which ensures that only the relevant JavaScript assets for each route are used. # Test Plan - CI - Manual testing with the Expo blog # 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) - [x] 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 View is getting strongly captured in some closures which keeps it's reference alive even after React unmounts component, causing memory leaks. <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How Weakly capture view reference to prevent retain cycle when view unmounts. <!-- How did you build this feature or fix this bug and why? --> # Test Plan Tested in NCL app with instruments. <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> # 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) - [x] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [x] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
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.
10 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 : )