[pull] main from expo:main #505
Merged
Conversation
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
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…app (#42269) # Why When running `expo export`, the logs would always show the following line: ```bash Static rendering is enabled. Learn more: https://docs.expo.dev/router/reference/static-rendering/ ``` # How The log has now been improved to detect when server rendering mode is enabled (i.e. `web.output: server` and `unstable_useServerRendering: true`. When both are set, the log now displays: ```bash Server rendering is enabled. Learn more: https://docs.expo.dev/router/web/server-rendering/ ``` Additionally, the link for static rendering has been updated to `https://docs.expo.dev/router/web/static-rendering/` # Test Plan - Manual testing # 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)
…42268) # Why The package scripts in `apps/router-e2e/package.json` had excessive/unused environment variables. # How Removed the excessive/unused environment variables. # Test Plan - Manual testing # Checklist - [ ] 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 Fixes: #42013 # 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)
…nstably override Metro config (#42082) # Why Radon IDE requires control over the Metro config. However, we usually don't allow this so we can now assume a specific type for the Metro config. We've never before exposed the `config` load option. The additional refactor in #41142 broke assumptions Radon made about how to override the config. # How Instead, we'll expose a `EXPO_OVERRIDE_METRO_CONFIG`, so we can officially maintain the override behaviour and document it in code. This is an environment variable rather than an argument, since we aim for users not to override the config loading process, so we can continue making assumptions about its type. The variable is passed straight to `resolveConfig`, and hence defaults, as per `metro-config` to be resolved from the current working directory as a path (or less recommended; a module specifier that `require` accepts). This **does** break the `import()` support in `loadConfig` for Windows, but we currently can't prevent this and this will instead be fixed by: facebook/metro@ef95470 - Add `EXPO_OVERRIDE_METRO_CONFIG` variable to override config path - Remove `LoadOptions` from `@expo/metro-config` as this was not directly used / defined in place (`config` option on it wasn't actually used, so removing this) # Test Plan - CI should pass # 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)
…ption (#42222) # Why Fixes `java.lang.IllegalStateException: Failed to build unique file`. It occurs when trying to create too many assets with the same filename in the same album. By default, the Content Resolver can resolve this issue for up to 32 assets, but then it throws this exception. This problem occurred occasionally in the test suite when some assets weren't successfully deleted. # How Adds fallback that appends part of a UUID to the filename when exception is thrown. # Test Plan Adds stress tests to BareExpo
# Why Adds the ExpoGo tag to the contacts@next docs # How Adds 'expo-go' flag in `contacts-next.mdx` # Test Plan Run locally
Co-authored-by: Aman Mittal <amandeepmittal@live.com>
…#42192) # Why The previous API had two separate but similar component hierarchies for configuring navigation headers: - `<Toolbar>` - for bottom toolbar items - `<Stack.Header.*>` - for header left/right items (Button, Menu, Spacer, View) This duplication required maintaining parallel implementations. Unifying them under `<Stack.Toolbar>` provides a cleaner, more consistent API that matches the iOS native mental model where both navigation bar items and bottom toolbar items share the same component types. # How - Created new `<Stack.Toolbar>` namespace that consolidates all toolbar-related components - Moved toolbar item components (`Button`, `Menu`, `Spacer`, `View`, etc.) from both `<Toolbar>` and `<Stack.Header.*>` into `<Stack.Toolbar.*>` - Added toolbar components: `Stack.Toolbar.Left`, `Stack.Toolbar.Right`, and `Stack.Toolbar.Bottom` - Simplified `<Stack.Header>` to only handle header styling (blur effect, background color, shadow) - children can be passed when `asChild` is used to generate custom header - Moved title and back button configuration to `<Stack.Screen.Title>` and `<Stack.Screen.BackButton>` - Removed the standalone `<Toolbar>` export (previously at `expo-router/unstable-toolbar`) # Test Plan 1. Manually test router-e2e native-navigation app (`yarn ios:native-navigation`/`yarn android:native-navigation`) 2. Maestro e2e tests run locally # 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)
…ema for validation (#42215) # Why Currently, `ajv` allows a `JSONSchema` to carry a "shadow type" which is then used by `validate` to assert this type. `@expo/schema-utils` doesn't have this functionality, but it reads a lot nicer when reusing schemas. # How - Add shadow type `JSONSchema<T>` that's used by `validate` as a type assertion - Add utility to `ValidationError` to just get stringified errors # Test Plan - n/a: no behavioural change # 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)
…ripts to create-expo (#41964) # Why Resolves #37793 We don't want `prebuild` to force-add `ios` and `android` scripts, since the user may have purposefully removed/replaced them. It's fine to keep the "switchover" logic but automatically adding the scripts should only be done in `create-expo-app`. # How - Remove auto-adding android/ios scripts when they're unset from prebuild script - Add auto-adding of android/ios when they're likely missing in a template # Test Plan - Unit test for `create-expo-app` added - CLI E2E test updated # 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)
…ls` (#42221) Stacked on #42215 Related to #42218 # Why `expo-dev-launcher`'s config plugin is still using the raw `ajv` library, which we've since replaced with `@expo/schema-utils`. This is leaner and has so far not caused any issues when replacing our prior implementations. # How - Replace ajv with `@expo/schema-utils` - Add missing `title` to schema and swap out types - Replace `validate` call # Test Plan - Existing tests should pass # 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)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
8 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 : )