Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
blakef opened this issue Mar 27, 2024 · 5 comments
Open

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

blakef opened this issue Mar 27, 2024 · 5 comments
Labels
question Further information is requested

Comments

@blakef
Copy link
Contributor

blakef commented Mar 27, 2024 •
edited

Background

As part of the move to support changes in the RFC-0759 React Native Frameworks, we're going to have to come up with a semver based versioning scheme to use with the @react-native-community/template package.

Proposal

  1. Track only the npm MINOR number, and use the latest PATCH
  2. Clean up the init command:
  --version <string>              Shortcut for `--template react-native@version`
  • version text should just read --template @react-native-community/template@version

Example

community-cli-template-scheme

As with the existing template, the version of React Native should be exactly pinned so users can manage upgrading from their template version manually. The downside of this approach is that we have to maintain this compatibility list as part of the release process, which no-longer is done for "free" as part of the react-native release process.

Problems

React Native version pinning

$ npx @react-native-community/cli init --version 0.75.0 Foobar

Currently we pin the version of React Native to each template release. Since the template was bound to the react-native npm package this wasn't an issue. We'd automatically get a release with each release of react-native. We no longer get this.

The first approach that comes to mind is:

  1. bump the PATCH version for every PATCH release of React Native. For example:
  • react-native@0.75.0 + template@0.75.0; template bug leads to template@0.75.1
  • react-native@0.75.1 + template@0.75.2
  • etc ...
  1. Update a map of some kind between { [react-native-version]: template-version } within the package.json that init can lookup using https://registry.npmjs.org/react-native/latest which is guaranteed to have all reverse lookups.
"name": "@react-native-community/template",
...
"react-native-versions": {
  "0.74.0": "0.74.0",
  "0.74.1": "0.74.0",
  "0.74.2": "0.74.0",
  "0.74.3": "0.74.0",
  "0.74.4": "0.74.0",
  "0.74.5": "0.74.0",
  "0.74.6": "0.74.1",
  "0.75.0-rc1": "0.75.0",
  "0.75.0-rc2": "0.75.1",
  "0.75.0-rc3": "0.75.2",
  "0.75.0": "0.75.2",
  "0.75.1": "0.75.3",
  ...
}

It's entirely possible that we can do some basic work to compress that a little (see the sequence of 0.74.0-5 with matching template version of 0.74.0), but for now it might be good just keep it simple.
@blakef blakef added the question Further information is requested label Mar 27, 2024
@cortinico
Copy link
Member

cortinico commented Mar 28, 2024 •
edited

The downside of this approach is that we have to

@blakef you have an unfinished sentence here.

Update a map of some kind between { [react-native-version]: template-version } within the package.json that init can lookup using https://registry.npmjs.org/react-native/latest which is guaranteed to have all reverse lookups.

IMHO this should be the preferred approach. I would not put the map inside the package.json but inside a file that the init command can easily access.

The logic could be something like:

  1. Users requested init --version 0.75.0-rc.1
    1. Check if the version mapping is present for the given version
      1. if yes use the template package at the specified version.
      2. if not, align the package to the minor version (so get the highest 0.75.x version of template you can find).
  2. Users requested init --version next (or any other NPM tag)
    1. Resolve the tag and follow the same mapping algorithm mentioned above

@thymikee
Copy link
Member

Do we really need the mapping? Unless there are breaking changes disguised as minor released, it shouldn't be problematic for any 0.75.x RN version to download any 0.75.y template. Keeping the mappings is gonna be a hassle for maintenance imho

@blakef
Copy link
Contributor Author

blakef commented Apr 2, 2024

Thanks @cortinico and @thymikee.

@thymikee sure, I guess we can guarantee that template 0.75.<latest> works with react-native 0.75.<latest>. If folks want to step outside of that, then they're going to have to know what they're doing.

Upgrade Helper

One thing to consider is that rn-diff-purge assumes that the template and react-native have a 1:1 relationship. This would change that.

We can probably tweak rn-diff-purge to match these using https://registry.npmjs.org/react-native and the npmjs registry data:

curl https://registry.npmjs.org/react-native | jq '.time | with_entries(select(.key | test("-nightly-") | not)) | to_entries | sort_by(.value) | from_entries'

Gives us this:

  ...
  "0.73.4": "2024-02-06T01:41:46.299Z",
  "0.74.0-rc.0": "2024-02-21T17:45:56.390Z",
  "0.73.5": "2024-02-26T19:11:08.247Z",
  "0.71.17": "2024-02-27T02:12:54.109Z",
  "0.74.0-rc.1": "2024-02-27T02:18:33.641Z",
  "0.72.11": "2024-02-28T18:14:47.759Z",
  "0.74.0-rc.2": "2024-03-04T20:50:40.367Z",
  "0.73.6": "2024-03-11T10:31:58.694Z",
  "0.74.0-rc.3": "2024-03-11T16:10:27.937Z",
  "0.72.12": "2024-03-11T17:04:21.206Z",
  "0.74.0-rc.4": "2024-03-18T16:31:36.248Z",
  "0.74.0-rc.5": "2024-03-25T16:14:40.545Z",
  "0.74.0-rc.6": "2024-04-02T12:14:10.038Z",
  "modified": "2024-04-02T12:14:10.205Z"

Which we can correlate with template releases and update the rn-diff-purge's new-release.sh script to more accurately capture the correct react-native:template relationship.

TL;DR / Outcome

We don't need a version table (that would have to be maintained). For projects that may require this, then can match the specified version of react-native to the template at the time using npm's API.

blakef added a commit to blakef/cli that referenced this issue Apr 3, 2024
@blakef
feat: check npm and github for template
953a319 
Support RFC-0759 decoupling of template from react-native. This makes
use of the new @react-native-community/template project. We're careful
to validate against what npm and github show for the state of the
react-native project.

New Template:

This will enable the new @react-native-community/template only if it
published on npm and the react-native/template doesn't exist for the
specific version of react-native selected.

There's more discussion about how template version and react-native
version should be related to each other in react-native-community#2345.
@blakef blakef mentioned this issue Apr 3, 2024
Merged
2 tasks
blakef added a commit to blakef/cli that referenced this issue Apr 3, 2024
@blakef
feat: check npm and github for template
0f3cef6 
Support RFC-0759 decoupling of template from react-native. This makes
use of the new @react-native-community/template project. We're careful
to validate against what npm and github show for the state of the
react-native project.

New Template:

This will enable the new @react-native-community/template only if it
published on npm and the react-native/template doesn't exist for the
specific version of react-native selected.

There's more discussion about how template version and react-native
version should be related to each other in react-native-community#2345.
@kelset
Copy link
Member

kelset commented Apr 5, 2024

Sorry it took me a while to get around to comment here - I have been having mixed feelings about the versioning scheme having to be a 1:1 relationship with the npm react-native releases but I think that ultimately it is the right call.

Blake, as you mentioned already, upgrade-helper has that as an expectation to work properly, and in a way we also want people to have this template and DX flow to behave exactly as before in order to minimise confusion. So with that in mind I think that even if it might just be a super small change (ex. the version in the package.json) this template should keep the 1:1.

blakef added a commit to blakef/cli that referenced this issue Apr 10, 2024
@blakef
feat: check npm and github for template
130b0de 
Support RFC-0759 decoupling of template from react-native. This makes
use of the new @react-native-community/template project. We're careful
to validate against what npm and github show for the state of the
react-native project.

New Template:

This will enable the new @react-native-community/template only if it
published on npm and the react-native/template doesn't exist for the
specific version of react-native selected.

There's more discussion about how template version and react-native
version should be related to each other in react-native-community#2345.
blakef added a commit to blakef/cli that referenced this issue Apr 10, 2024
@blakef
feat: check npm and github for template
36e5c36 
Support RFC-0759 decoupling of template from react-native. This makes
use of the new @react-native-community/template project. We're careful
to validate against what npm and github show for the state of the
react-native project.

New Template:

This will enable the new @react-native-community/template only if it
published on npm and the react-native/template doesn't exist for the
specific version of react-native selected.

There's more discussion about how template version and react-native
version should be related to each other in react-native-community#2345.
blakef added a commit to blakef/cli that referenced this issue Apr 10, 2024
@blakef
feat: check npm and github for template
10cdf38 
Support RFC-0759 decoupling of template from react-native. This makes
use of the new @react-native-community/template project. We're careful
to validate against what npm and github show for the state of the
react-native project.

New Template:

This will enable the new @react-native-community/template only if it
published on npm and the react-native/template doesn't exist for the
specific version of react-native selected.

There's more discussion about how template version and react-native
version should be related to each other in react-native-community#2345.
@thymikee
Copy link
Member

Realistically, to make sure we have the parity between RN releases and upgrade helper, we should set up some automation that's triggered from RN release webhook and match accordingly. We should also have the freedom to amend those versions for critical bug fixes. Like:

  • react-native@0.74.2 -> (triggers template release) ->
  • @react-native-community/template@0.74.2 -> (after bugfix) ->
  • @react-native-community/template@0.74.2-1

@blakef blakef mentioned this issue May 10, 2024
Open
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question Further information is requested
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@blakef @cortinico @thymikee @kelset