[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)

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]>

show more ...

[config-plugins][config-types] rebuild files (#20168)

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]>

show more ...

[config-plugins] Fix runtime version parsing on Android (#19821)

# Why

Fix the issue described in
https://linear.app/expo/issue/ENG-6212/fix-runtime-version-parsing-on-android
where trailing ze

[config-plugins] Fix runtime version parsing on Android (#19821)

# Why

Fix the issue described in
https://linear.app/expo/issue/ENG-6212/fix-runtime-version-parsing-on-android
where trailing zeroes are removed from Android runtime version values.

# How

Modify the existing updates code in
`@expo/config-plugins/src/android/Update.ts` to write the runtime
version as a string resource, and modify `UpdatesConfiguration.kt`
(expo-updates) to check for the runtime version in the string resource
first, and fall back to checking the manifest as before if the string
resource is not found.

# Test Plan

- New unit test added
- Tested in EAS builds and verified the expected metadata shows up in
the Android manifest, and the expected string shows up in the app's
`strings.xml`.

# Checklist

<!--
Please check the appropriate items below if they apply to your diff.
This is required for changes to Expo modules.
-->

- [ ] Documentation is up to date to reflect these changes (eg:
https://docs.expo.dev and README.md).
- [ ] 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).

show more ...

chore: migrate config, config-plugins, config-types, prebuild-config (#17958)