Conversation
…r deprecated native iOS methods (#43035) # Why We're exposing information from [CTCarrier](https://developer.apple.com/documentation/coretelephony/ctcarrier) which is deprecated with no replacement, as it exposes information that's (I suppose) privacy-sensitive. The apis currently return dummy values such as `--` instead of carrier name. Our docs don't reflect that. I also removed several constants that were deprecated long ago. closes #23256 # How - remove the old apis on native side and return `null`, same as on web # Test Plan - NCL # 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 The current capability identifier seems to have been used in beta, but it's no longer documented on apple developer website. # 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 === Expo Go builds are now uploaded to GitHub Releases (`expo/expo-go-releases`) via the `eas-dispatch ios-simulator-upload` and `eas-dispatch android-apk-upload` commands in `EasDispatch.ts`. The old `client-build` command uploaded to S3 (`exp-ios-simulator-apps` and `exp-android-apks` buckets) and is no longer used. Removing it lets us drop the `@aws-sdk/client-s3` dependency and the associated AWS credentials requirement from expotools entirely. How === Delete `tools/src/commands/ClientBuild.ts` and the entire `tools/src/client-build/` directory (`AndroidClientBuilder.ts`, `IosClientBuilder.ts`, `types.ts`). Remove `@aws-sdk/client-s3` from `tools/package.json` and regenerate the lockfile. Update the stale CloudFront URL example in the Release Workflow guide to use the GitHub Releases URL format. Test Plan === `yarn` in `tools/` succeeds. The `et eas ios-simulator-upload` and `et eas android-apk-upload` commands in `EasDispatch.ts` are unchanged and remain the active upload path.
# Why Fixed the alignment of the "Low Latency HLS" capability entry in the iOS capabilities documentation table. # How # Test Plan # Checklist - [x] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
# Why Due to some tricky byte operations in the caching mechanism, we would sometimes read/write the data with 1 byte offset leading to corrupted files. # How - Fix data range access isues - Remove NSLock deadlock - addDataRange() was calling loadedDataRanges property getter which tried to re-acquire the lock - Added a bunch of checks and logs to make debugging easier in the future if needed - Improved data access thread safety - Use Int64 to avoid issues for large files # Test Plan Tested in BareExpo on iOS
…43039) # Why Because the `Keyframe` was created in the global scope, the worklet assigned `setVisible` only once. Therefore when the `AnimatedSplashOverlay` was remounted, the "splash screen overlay" remained visible. Fixes: #42500 Full context - https://exponent-internal.slack.com/archives/CGHFEK33M/p1770717235914549 ## Before https://github.com/user-attachments/assets/40d12010-b7b4-4e67-b696-10419ee5e795 ## After https://github.com/user-attachments/assets/963eb889-f05d-4eab-b5c4-d7e9e00046a6 # How Move the `Keyframe` creation to the component scope # Test Plan Manual testing # 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)
…ield workflow (#42894) # Why Currently we've established some basic workflow for validating brownfield that includes E2E test suites for CLI and for the plugin. We're also currently adding Maestro-based E2E tests validating the integration with native apps and the functionality of the `expo-brownfield` APIs (with plans to extend to test `expo-dev-menu`, `expo-updates`, etc. after the base setup is added). However, this is not enough (or sometimes more than enough) to test changes which might affect `expo-brownfield` components. # How ## Main change Updated the `brownfield.yml` workflow to be more modular and optimized using `dorny/paths-filter`. This PR divides brownfield tests into four groups: - E2E for CLI - jest-based E2E tests for the brownfield CLI - E2E for plugin - jest-based E2E tests for `expo-brownfield` config plugin - Compilation test - simply validates that brownfield can successfully compile with the changes (new, added in this PR) - E2E for integration - Maestro-based E2E tests (not incl. in this PR, currently in progress) To optimally execute them this PR proposes the following triggers: ### `e2e-cli` Verifies the functionality of the CLI and handling of various arguments and flags. Those tests don't run any compilation, building or publishing and only output which commands would be called with what arguments (using the `--dry-run` option). Proposed triggers: - This workflow - `expo-brownfield/bin` - `expo-brownfield/cli` - `expo-brownfield/e2e/cli` - `expo-brownfield/e2e/utils` - `expo-brownfield/package.json` - `yarn.lock` ### `e2e-plugin` Verifies the functionality of the config plugin and handling of various configuration options (and inference of defaults). Prebuilds a temporary project with the plugin and validates the generated native directories. Proposed triggers: - This workflow - `expo-brownfield/plugin` - `expo-brownfield/e2e/plugin` - `expo-brownfield/e2e/utils` - `expo-brownfield/app.plugin.js` - `expo-brownfield/package.json` - `yarn.lock` ### `Compilation test` Compiles brownfield artifacts from `brownfield-tester/expo-app` in both `Debug` and `Release` variants (`All` on Android). It will help us to detect changes which are breaking the brownfield early. It uses the config plugin, CLI and all APIs offered by the brownfield module, so it validates all basics of the package. Proposed triggers: - This workflow - `expo-brownfield/` (temporarily while we wrap up the Maestro tests) - Selected paths in: - `expo` - `expo-dev-menu` - `expo-manifests` - `expo-updates` (currently as commented TODO, we might want to include it in the future) - `yarn.lock` ### `Maestro E2Es` E2E tests verifying the functionality of brownfield (and its APIs) and integration with various packages (e.g. `expo-dev-menu`, `expo-router`, etc.). Proposed triggers: - The workflow for the tests (`test-suite-brownfield-isolated.yml`) - `expo-brownfield` - Schedule based trigger (maybe once a week) ## Additional changes - All tests for the config plugin are now running on ubuntu runners # Test Plan - Ensured all tests pass on 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).
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.
7 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 : )