Repository navigation
Proposal: @react-native-community/template versioning scheme #2345
Description
Activity
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.jsonbut inside a file that theinitcommand can easily access.The logic could be something like:
- Users requested
init --version 0.75.0-rc.1- Check if the version mapping is present for the given version
- if yes use the
templatepackage at the specified version. - if not, align the package to the minor version (so get the highest
0.75.xversion of template you can find).
- if yes use the
- Check if the version mapping is present for the given version
- Users requested
init --version next(or any other NPM tag)- Resolve the tag and follow the same mapping algorithm mentioned above
Reacted by Michał Pierzchała and Blake Friedman- Users requested
Do we really need the mapping? Unless there are breaking changes disguised as minor released, it shouldn't be problematic for any
0.75.xRN version to download any0.75.ytemplate. Keeping the mappings is gonna be a hassle for maintenance imhoReacted by Nicola Corti and Lorenzo SciandraThanks @cortinico and @thymikee.
@thymikee sure, I guess we can guarantee that template
0.75.<latest>works with react-native0.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-nativeto thetemplateat the time using npm's API.Reacted by Nicola Corti and Brent Vatne- added 2 commits that reference this issue
on Apr 3, 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-nativereleases 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.
- added 3 commits that reference this issue
on Apr 10, 2024 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
Reacted by Blake Friedman- added a commit that references this issue
on Jun 17, 2024 - added a commit that references this issue
on Jun 18, 2024 Btw, the issue with
0.74.2-1is that it's treated as a prerelease by npm and would need to be declared explicitly as a dependency (which is already happening anyway)Reacted by Szymon RybczakClosing this issue as I think we've already discussed implementation's details and PR with final version is ready: #2475!
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
initcommand:--template @react-native-community/template@versionExample
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-nativerelease process.Problems
React Native version pinning
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:
{ [react-native-version]: template-version }within thepackage.jsonthatinitcan lookup usinghttps://registry.npmjs.org/react-native/latestwhich is guaranteed to have all reverse lookups.It's entirely possible that we can do some basic work to compress that a little (see the sequence of
0.74.0-5with matching template version of0.74.0), but for now it might be good just keep it simple.