[pull] main from expo:main #539
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
#42626) # Why Followup to #42516. After using `require.resolve()` to locate `@expo/router-server`, the last issue was `unstable_headers` in `expo-router` which was re-exported from `@expo/router-server`. Since server components and API routes both might need access to request headers for common use cases like authentication and reading custom headers, it would be preferable to have a stable API for this from `expo-server`. # How This PR adds an exposes a new runtime API function called `requestHeaders()` which returns an `ImmutableHeaders` object created from the original `Headers` supplied by the request. # Test Plan - CI # 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 `@expo/cli` still had logic for the SDK 51 method of generating typed routes. Since SDK 51 is now unsupported, it should be safe to remove this. # How Removed the "legacy" method of generating typed routes from `type-generation/routes.ts`. # Test Plan - CI # 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 Relanding #42449 after the necessary changes in Expo Go in #42577 # How Run `git cherry-pick a047cf3` # Test Plan Run BareExpo locally # 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)
…for import" (#42507) # Why <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> I was testing out the `expo-widgets` alpha and installed it to my Expo 55 beta app. When I deleted my `ios/` and ran `npx expo run:ios`, it resulted in the following error: <details><summary>`npx expo run:ios` Error Logs</summary> <p> ``` › Compiling Pods/Pods-ExpoWidgetsTarget » Pods-ExpoWidgetsTarget-dummy.m › Packaging Pods/Pods-ExpoWidgetsTarget » libPods-ExpoWidgetsTarget.a › Executing RecallKit/ExpoWidgetsTarget » [CP] Check Pods Manifest.lock › Preparing RecallKit/ExpoWidgetsTarget » Info.plist › Executing RecallKit/ExpoWidgetsTarget » [Expo] Configure project › Compiling expo-dev-menu Pods/expo-dev-menu » RCTKeyCommands.m › Compiling expo-dev-menu Pods/expo-dev-menu » expo-dev-menu-dummy.m › Linking RecallKit/ExpoWidgetsTarget » __preview.dylib ❌ (ios/ExpoWidgetsTarget/index.swift:3:8) 1 | import WidgetKit 2 | import SwiftUI > 3 | import ExpoWidgets | ^ ambiguous implicit access level for import of 'ExpoWidgets'; it is imported as 'internal' elsewhere 4 | 5 | @main 6 | struct ExportWidgets0: WidgetBundle { ❌ (ios/ExpoWidgetsTarget/RecallKit.swift:3:8) 1 | import WidgetKit 2 | import SwiftUI > 3 | import ExpoWidgets | ^ ambiguous implicit access level for import of 'ExpoWidgets'; it is imported as 'internal' elsewhere 4 | 5 | struct RecallKit: Widget { 6 | let name: String = "RecallKit" ❌ (ios/ExpoWidgetsTarget/index.swift:3:8) 1 | import WidgetKit 2 | import SwiftUI > 3 | import ExpoWidgets | ^ ambiguous implicit access level for import of 'ExpoWidgets'; it is imported as 'internal' elsewhere 4 | 5 | @main 6 | struct ExportWidgets0: WidgetBundle { ❌ (ios/ExpoWidgetsTarget/RecallKit.swift:3:8) 1 | import WidgetKit 2 | import SwiftUI > 3 | import ExpoWidgets | ^ ambiguous implicit access level for import of 'ExpoWidgets'; it is imported as 'internal' elsewhere 4 | 5 | struct RecallKit: Widget { 6 | let name: String = "RecallKit" ❌ (ios/ExpoWidgetsTarget/index.swift:3:8) 1 | import WidgetKit 2 | import SwiftUI > 3 | import ExpoWidgets | ^ ambiguous implicit access level for import of 'ExpoWidgets'; it is imported as 'internal' elsewhere 4 | 5 | @main 6 | struct ExportWidgets0: WidgetBundle { ❌ (ios/ExpoWidgetsTarget/RecallKit.swift:3:8) 1 | import WidgetKit 2 | import SwiftUI > 3 | import ExpoWidgets | ^ ambiguous implicit access level for import of 'ExpoWidgets'; it is imported as 'internal' elsewhere 4 | 5 | struct RecallKit: Widget { 6 | let name: String = "RecallKit" ❌ (ios/ExpoWidgetsTarget/index.swift:3:8) 1 | import WidgetKit 2 | import SwiftUI > 3 | import ExpoWidgets | ^ ambiguous implicit access level for import of 'ExpoWidgets'; it is imported as 'internal' elsewhere 4 | 5 | @main 6 | struct ExportWidgets0: WidgetBundle { ❌ (ios/ExpoWidgetsTarget/RecallKit.swift:3:8) 1 | import WidgetKit 2 | import SwiftUI > 3 | import ExpoWidgets | ^ ambiguous implicit access level for import of 'ExpoWidgets'; it is imported as 'internal' elsewhere 4 | 5 | struct RecallKit: Widget { 6 | let name: String = "RecallKit" › Compiling expo-dev-menu Pods/expo-dev-menu » EXDevMenuAppInfo.m › Packaging expo-dev-menu Pods/expo-dev-menu » libexpo-dev-menu.a › Executing expo-dev-menu Pods/expo-dev-menu » Copy generated compatibility header Run script build phase '[CP-User] [Hermes] Replace Hermes for the right configuration, if needed' will be run during every build because it does not specify any outputs. To address this issue, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'hermes-engine' from project 'Pods') Run script build phase 'Upload Debug Symbols to Sentry' will be run during every build because it does not specify any outputs. To address this issue, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'RecallKit' from project 'RecallKit') Run script build phase '[CP-User] Generate updates resources for expo-updates' will be run during every build because it does not specify any outputs. To address this issue, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'EXUpdates' from project 'Pods') › 8 error(s), and 3 warning(s) CommandError: Failed to build iOS project. "xcodebuild" exited with error code 65. ``` </p> </details> I am not an iOS dev, but based on my brief investigation: - This is because `expo-modules-autolinking` generates `internal import ${moduleName}` for all Swift modules. - I do see this in the source code for `expo-modules-autolinking@55.0.1` at `src/platforms/apple/apple.ts`: [[npm source code](https://www.npmjs.com/package/expo-modules-autolinking/v/55.0.1?activeTab=code)]. I'm not sure which branch this version is published from - Before 55.0.1, it used `@_implementationOnly import ${moduleName}` instead: [[source code on main](https://github.com/expo/expo/blob/main/packages/expo-modules-autolinking/src/platforms/apple/apple.ts#L194-L196)] - `expo-widgets` generates `import ExpoWidgets` via [`withWidgetSourceFiles.ts `](https://github.com/expo/expo/blob/main/packages/expo-widgets/plugin/src/withWidgetSourceFiles.ts#L50-L52) - `internal import` syntax is a Swift 6 feature [[SE-0409]](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0409-access-level-on-imports.md) - Thus, `expo-modules-autolinking` was updated to use `internal import` for Swift 6 compatibility, but `expo-widgets` config plugin wasn't updated to match yet - The differing access levels results in the the compiler throwing "ambiguous implicit access level for import". Relevant environment details: ``` expo: 55.0.0-preview.5 expo-widgets: 55.0.0-alpha.2 XCode 26 ``` > [!NOTE] > EDIT: I see this was introduced #42449! But was reverted. So the revert likely didn't get published yet? See comment below as we might not need this PR. # How <!-- How did you build this feature or fix this bug and why? --> The solution here is to also update `expo-widgets` to use `internal import` to match the output from `expo-module-autolinking`. Apologies for the lazy commit messages. # 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. --> Used to get the error when running `npx expo run:ios` on my app, after patching with this fix, it compiled perfectly and I was able to use the `expo-widget` functionality. # 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)
… typings, bump `@expo/xcpretty` (#42485) # Why It's unclear why the dependency ranges in a few spots are restricted to old patches. This affects `@expo/config` and `@expo/json-file`. It's also caused by `@expo/xcpretty`. This duplicates this package in some setups, or in the case of `expo/expo` and other cases, keeps it to an old version, depending on the top-level Babel version. # How - Add `import` typings annotation - Move `@expo/json-file`'s usage of `@babel/code-frame` to lazy require to mirror `@expo/config` - Extend `@babel/code-frame` dependency range and bump typings version - Bump `@expo/xcpretty` # Test Plan - Manually tested that function works unchanged - CI should cover the rest # 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>
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 : )