Proposal: @react-native-community/template versioning scheme about cli HOT 5 OPEN

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

from cli.

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

from cli.

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.

from cli.

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:

• [email protected] -> (triggers template release) ->
• @react-native-community/[email protected] -> (after bugfix) ->
• @react-native-community/[email protected]

from cli.

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.

from cli.