Conversation
…subtitle tracks (#43250) # Why While creating our HLS test stream i learned about these fields and they are important for track selection so it's good to expose them to JS # How Extract and add the `NAME`, `DEFAULT`, and `AUTOSELECT` tags from the manifest # Test Plan Tested in BareExpo on Android and iOS
# Why The environment is currently being instantiated by resolving `@expo/env` from `expo`. Failing to load this results in an error. However, the actual dependency chain is `expo -> @expo/cli -> @expo/env` (and some others), which means that this has a chance of failing, which would in turn fail `ExpoConfigLoader`. We have three options here: - expose the exact config loading procedure that `@expo/cli` uses via `expo/internal/*` (requires a large refactor that requires us to unify the `@expo/env` loading and `@expo/config` loading — we should do this but this will be likely a breaking change) - fix the resolution chain by turning the double-resolution into a triple-resolution - add `@expo/env` as a dependency to `@expo/fingerprint` and rely on it either being the same or not mattering This PR goes for the third option for simplicity for now. This isn't quite the same and may impact the module loader cache, so the `@expo/env` loading has been moved before the module loader cache capturing. **This makes this a change that'll affect the project fingerprint.** # How - Add `@expo/env` as a dependency to `@expo/fingerprint` and load it directly - Make sure we load the env files **after** setting `NODE_ENV=development` - This is the default, however, being explicit would be better, since it can technically be overridden otherwise. This would lead to us loading the config with `NODE_ENV=development` while sourcing the env files from another environment - **Unrelated:** Add type declaration for `module._cache` # Test Plan - Existing tests # 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 closes #42900 Adds support for native preloading # How Adds a `preload` function and cache that allows users to create a player instance and start loading the buffer ahead of when `useAudioPlayer` is used in the component. When a url is used that exist's in the cache, we return the preloaded `AVPlayer` instance. # Test Plan Bare expo
# Why Adds support for native preloading # How Adds a `preload` function and cache. Uses media3's `CacheDataSource`. # Test Plan Bare expo
# Why Supports preloading on web # How Same approach as when `downloadFirst` was added except we also add `audio.preload = 'auto';` Extracted some of the shared logic from `downloadFirst` so all forms of preloading go through the same mechanism and use the cache. # Test Plan Bare expo.
…aderPackagesProviderInterface` (#43260)
…#42943) This indicates that the error path inside `onCreate` calls `finish()` while `videoViewId` is still uninitialized. Crash Log ``` Fatal Exception: java.lang.RuntimeException: Unable to start activity ComponentInfo{hoge/expo.modules.video.FullscreenPlayerActivity}: kotlin.UninitializedPropertyAccessException: lateinit property videoViewId has not been initialized ``` # How - Made `videoViewId` nullable and guarded its use in `finish()` to avoid `UninitializedPropertyAccessException`. - Made `orientationHelper` nullable and guarded lifecycle calls to avoid similar issues if initialization fails early. # Test Plan - passed 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). - [x] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…stemAPI` flag (#43251) # Why When `useWatchman: true` is set, which it is due to the default values from the default Metro config, the `resolver.useWatchman` flag is coupled to disable `forceNodeFilesystemAPI`: https://github.com/facebook/metro/blob/b9c243f/packages/metro/src/node-haste/DependencyGraph/createFileMap.js#L109 Unfortunately, this flag enables the native `find` binary, when it's available: https://github.com/facebook/metro/blob/b9c243fb93b86338f15b3d779b41697cc001e1ef/packages/metro-file-map/src/crawlers/node/index.js#L195-L198 I've traced a slowdown of CLI startups (when watchman is not installed of course) back to this `find` code path, which in `apps/router-e2e` can be around 6s. Disabling this flags brings the time down a lot. This seems to be an extremely performance-sensitive code path. I'm not sure if `graceful-fs` is slowing it down, or it could be rewritten, but it also doesn't yet seem to be as fast as it could be. However, it is already seemingly faster than the `useNativeFind` code path. This reduces the delay until bundling can start. # How As long as `useWatchman` is `null | undefined`, it'll still be enabled by default but `forceNodeFilesystemAPI` will be activated as a hidden "third state". https://github.com/facebook/metro/blob/b9c243fb93b86338f15b3d779b41697cc001e1ef/packages/metro-file-map/src/index.js#L326 - Set `resolver.useWatchman` to `undefined` by default in `@expo/metro-config` - In `instantiateMetro`, force it to `null` when it's set to `true` This disables the `useNativeFind` codepath entirely. # Test Plan - Run `expo start` in `apps/router-e2e` without watchman installed - Alternatively, patch `useNativeFind = false` into `metro-file-map/src/crawlers/node/index.js`. - to time this, modify `metro-file-map/src/crawlers/node/index.js` around the `perfLogger` calls with a `console.time` and `console.timeEnd` # 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)
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 : )