feat: determine react-native → template from npm registry data #2475

blakef · 2024-08-16T13:55:16Z

Summary:

How?

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:

$ curl --silent https://registry.npmjs.org/@react-native-community%2ftemplate | jq '.versions[] | {scripts: .scripts,version: .version}'

{
  "scripts": {
    "version": "0.75.0-nightly-20240618-5df5ed1a8"
  },
  "version": "0.76.0-nightly-20240621-e2b44a9"
}
...
{
  "scripts": {
    "version": "0.75.0-rc.6"
  },
  "version": "0.75.0-rc.6"
}
...

and

$ curl --silent https://registry.npmjs.org/@react-native-community%2ftemplate | jq '.time'

{
  "created": "2024-06-17T11:02:34.827Z",
  "modified": "2024-08-15T12:33:44.181Z",
  "0.75.0": "2024-06-14T17:10:22.041Z",
  "0.76.0-nightly-202487-8f93044": "2024-08-07T10:39:59.938Z",
  "0.75.1": "2024-08-15T12:33:41.781Z"
  ...
}

We use this data from the CLI to figure out which template to install when running npx @react-native-community/init.

Why?

This means that we 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 candidates 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 release another version of the template with the fix. As long as react-native@0.75.0 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

Example

If you run npx @react-native-community/cli init Foobar where the latest version points to the React Native version on the bottom line. On:

Monday (A) it'll install 0.75.0 from template 0.75.0.
Tuesday it'll install 0.75.1 from template 0.75.1 but after publishing a new release of the template this will be from template 0.75.2. Similarly from (B) the version of the template bumps a PATCH for a patch release, but still pointing to react-native 0.75.1.

Test Plan:

I've created further unit tests as well as pulling out the important template version selection code and creating unit tests for that, reflecting semantics only captured in comments.

Checklist

Documentation is up to date to reflect these changes.
Follows commit message convention described in CONTRIBUTING.md

blakef · 2024-08-16T14:09:54Z

Looking into the E2E test failures.

cortinico · 2024-08-16T14:11:12Z

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.

Does this mean we still need to publish a version of the template for each version of react-native though?

blakef · 2024-08-16T14:43:00Z

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.

Does this mean we still need to publish a version of the template for each version of react-native though?

Yes, but because you still need a template with the version of "react-native": "<version>" set in it's package.json.

What this change means is that if we release 0.75.2 and the template has a problem we could release another version of the template with "react-native": "0.75.2" and the next time a user tried to initialise a project with 0.75.2 it'd use the updated template.

Other changes needed:

@react-native-community/template GHA for the release should specify the react native version as a separate input. I'd recommend we also only take MAJOR.MINOR for the template version, and the action just +1 to PATCH.
The react-native release GHA action would have to be updated to use this.

blakef · 2024-08-19T10:36:02Z

These failures are because the android autolinking calls npx @react-native-community/cli config and gives a 127 error code. That's normally because it can't find the command. First thoughts are it can't find npx, but I'm not sure about that.

Otherwise I've updated snapshots.

This feature needs to be released with react-native-community/cli#2475, which decouples the 1:1 release model we have for templates and react-native. Switching users to this is going to be difficult, and should only be rolled asap before 0.76. If we have to release a template fix, then only users with the latest CLI will be able to use that and subsequent versions. I'm not sure of how to clearly communicate that to users.

szymonrybczak · 2024-08-30T07:05:26Z

__e2e__/__snapshots__/config.test.ts.snap

@@ -4,9 +4,29 @@ exports[`shows up current config without unnecessary output 1`] = `
 {
  "root": "<<REPLACED_ROOT>>/TestProject",
  "reactNativePath": "<<REPLACED_ROOT>>/TestProject/node_modules/react-native",
-  "reactNativeVersion": "0.74",
+  "reactNativeVersion": "0.75",


After rebasing CI should be green.

szymonrybczak

🙏 Thanks for also adding tests!

packages/cli/src/tools/__tests__/npm-test.ts

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 react-native@0.75.0 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

This feature needs to be released with react-native-community/cli#2475, which decouples the 1:1 release model we have for templates and react-native. Switching users to this is going to be difficult, and should only be rolled asap before 0.76. If we have to release a template fix, then only users with the latest CLI will be able to use that and subsequent versions. I'm not sure of how to clearly communicate that to users. - Added tests - Set dry_run to default

…43) This feature needs to be released with react-native-community/cli#2475, which decouples the 1:1 release model we have for templates and react-native. Switching users to this is going to be difficult, and should only be rolled asap before 0.76. If we have to release a template fix, then only users with the latest CLI will be able to use that and subsequent versions. I'm not sure of how to clearly communicate that to users. - Added tests - Set dry_run to default

blakef requested review from adamTrz and thymikee as code owners August 16, 2024 13:55

github-actions bot added the feature label Aug 16, 2024

blakef force-pushed the feat/use-npm-registry branch from df0647c to a5cfebe Compare August 16, 2024 14:26

blakef mentioned this pull request Aug 19, 2024

feat: create releases where PATCH doesn't have to match react-native react-native-community/template#43

Merged

blakef requested a review from szymonrybczak August 27, 2024 16:01

szymonrybczak reviewed Aug 30, 2024

View reviewed changes

szymonrybczak approved these changes Aug 30, 2024

View reviewed changes

szymonrybczak reviewed Aug 30, 2024

View reviewed changes

packages/cli/src/tools/__tests__/npm-test.ts Show resolved Hide resolved

blakef force-pushed the feat/use-npm-registry branch from 7eaeb5e to 800ccc2 Compare August 30, 2024 12:21

blakef force-pushed the feat/use-npm-registry branch from 800ccc2 to 096dfc2 Compare August 30, 2024 12:24

szymonrybczak mentioned this pull request Aug 30, 2024

Proposal: @react-native-community/template versioning scheme #2345

Closed

blakef merged commit e3bc0dd into main Sep 2, 2024
10 checks passed

This was referenced Oct 8, 2024

fix/ios xcworkspace with extra files blakef/cli#3

Closed

fix/ios xcworkspace with extra files blakef/cli#4

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: determine react-native → template from npm registry data #2475

feat: determine react-native → template from npm registry data #2475

blakef commented Aug 16, 2024 •

edited

Loading

blakef commented Aug 16, 2024

cortinico commented Aug 16, 2024

blakef commented Aug 16, 2024

blakef commented Aug 19, 2024

szymonrybczak Aug 30, 2024

szymonrybczak left a comment

feat: determine react-native → template from npm registry data #2475

feat: determine react-native → template from npm registry data #2475

Conversation

blakef commented Aug 16, 2024 • edited Loading

Summary:

How?

Why?

What does this do?

Example

Test Plan:

Checklist

blakef commented Aug 16, 2024

cortinico commented Aug 16, 2024

blakef commented Aug 16, 2024

blakef commented Aug 19, 2024

szymonrybczak Aug 30, 2024

Choose a reason for hiding this comment

szymonrybczak left a comment

Choose a reason for hiding this comment

blakef commented Aug 16, 2024 •

edited

Loading