[expo-updates] Add fingerprintExperimental runtime version policy (#24126)# Why Manually handling runtimeVersions is a big pain for projects that uses native modules. This PR adds a new runtime
[expo-updates] Add fingerprintExperimental runtime version policy (#24126)# Why Manually handling runtimeVersions is a big pain for projects that uses native modules. This PR adds a new runtime policy that handles this automatically. See: https://discord.com/channels/695411232856997968/1142023605908156476/1142023605908156476 # How Using [expo-fingerprint](https://github.com/expo/expo/tree/main/packages/@expo/fingerprint#readme) to auto-generate a hash for the project. # Test Plan I made the changes locally on a working project and the build was successfully with expo prebuild. I checked the native files and the runtime version was set to the project hash. # Checklist - [x] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [x] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [x] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). --------- Co-authored-by: Expo Bot <[email protected]> Co-authored-by: Aman Mittal <[email protected]> Co-authored-by: Kudo Chien <[email protected]> Co-authored-by: Douglas Lowder <[email protected]>
show more ...
[config-types] Remove classic updates (#24066)
[config-plugins][updates] Add support for config.updates.useClassicUpdates defaulting behavior (#22169)
[config-types][config-plugins] additional values for updates.checkAutomatically (#22119)
chore(prebuild-config, config-plugins): rewrite tests to use latest template for fixtures (#21339)# Why - The previous tests were using static representations of the versioned fixtures. This me
chore(prebuild-config, config-plugins): rewrite tests to use latest template for fixtures (#21339)# Why - The previous tests were using static representations of the versioned fixtures. This meant that many tests were possibly outdated. - Now that the CLI is versioned, we can test against the latest templates to ensure our config plugins are always up to date. <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How - Pull in fixtures from the local template. - Rewrite tests to work with new fixtures. <!-- How did you build this feature or fix this bug and why? --> # Test Plan - Tests should continue to pass. --------- Co-authored-by: Expo Bot <[email protected]>
Add requestHeaders option in app.js to avoid issues with expo prebuild when using release channels outside EAS build (#18737)# Why On the documentation [https://docs.expo.dev/bare/updating-your
Add requestHeaders option in app.js to avoid issues with expo prebuild when using release channels outside EAS build (#18737)# Why On the documentation [https://docs.expo.dev/bare/updating-your-app/](https://docs.expo.dev/bare/updating-your-app/) is stated that you can configura the release channel manually by adding `expo.modules.updates.UPDATES_CONFIGURATION_REQUEST_HEADERS_KEY` or `EXUpdatesRequestHeaders` in their respective places. However, `expo prebuild` does not consider this option resulting in missing or removed release channel configuration. The proposed solution introduces a new configuration option in app.json updates section called `requestHeaders` that allows to handle this configuration automatically, just like `codeSigningMetadata`. # How I followed precisely how `codeSigningMetadata` option is implemented (styles, names, etc) and modified: `packages/@expo/config-types/src/ExpoConfig.ts` Added `requestHeaders` option under updates in order to update the schema `packages/@expo/config-plugins` I updated iOS and Android Updates.ts and added the relative helpers and tests, closely follwing how `codeSigningMetadata` was implemented It is possible now to add the updates request headers directly in `app.json` and have `expo prebuild` handle this configuration automatically. # Test Plan I have included the relative tests following the behavior of `codeSigningMetadata` option. I have also tested on a real project by copying the builds of config-plugins in the node_modules folder.  # Checklist - [X] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [X] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [X] This diff will work correctly for `expo prebuild` & EAS Build (eg: updated a module plugin). NOTE: I have updated the relevant documentation page `docs/pages/bare/updating-your-app.md` but not the `app.json / app.config.js` as I thought adding instructions to add release channel information in app.js may confuse managed expo users. Co-authored-by: Will Schurman <[email protected]> Co-authored-by: Douglas Lowder <[email protected]> Co-authored-by: Bartosz Kaszubowski <[email protected]> Co-authored-by: Douglas Lowder <[email protected]>
feat(config-plugins): add `appVersion` runtime policy (#18398)
chore: migrate config, config-plugins, config-types, prebuild-config (#17958)