Skip to content

Conversation

blakef
Copy link
Owner

@blakef blakef commented Aug 16, 2024

When we trigger a release of the template, we capture the version of
react-native it's built with in the scripts.version field. This is
accessible for all version of the template.

We use this store from the CLI to figure out which template to install
from when running `init`.

Why?

This means that we can effectively decouple our package version from the
react-native package version. The 1:1 version mapping was done as a stop-gap
in the 0.74 release, because of problems with release candiates and semver
ordering. E.g. 0.75.0, 0.75.0-rc1, 0.75.0-rc2, etc... don't order
sanely.

What does this do?

For example, if we discover a bug in the template for 0.75.0, previously
we'd have to:
- get react-native to run another release (very expensive), or
- change the init logic (see 0.75.0-rc1.1 as an example).

Now we just release another version of the template with the fix. As long as
[email protected] is still set as the version, the cli will pick the
latest published version of the template with a matching version.

See the commit for more details about exactly how version are picked.

[0] https://github.com/react-native-community/template/blob/main/scripts/updateReactNativeVersion.js#L66-L93
@blakef blakef force-pushed the feat/use-npm-registry branch from 800ccc2 to 096dfc2 Compare August 30, 2024 12:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant