Remove publishing monorepo packages from main

[lunaleaps]

Problem

Today's release process involves releasing react-native and all the monorepo dependencies. Even though they are independently versioned, in reality, they all should be released in lock-step.

When we cut a release today, say for 0.74, we publish all the monorepo package at version 0.75 from main and point react-native on main to use these. We used to do this because we did not publish nightly monorepo packages and needed these versions for nightly react-native.

Now that we do publish monorepo nightlies, we no longer need this step. It also causes some weirdness because we have monorepo packages with 0.75.0 when there is no 0.75 react-native.

Proposal

• Adjust this step in the release process to not publish those monorepo packages but instead update their version on main

Questions

• How will this affect out-of-tree platforms? What version of monorepo packages do they use? Can they use nightly versions of monorepo packages instead or perhaps latest stable version?
  • It seems like someone is using these main publishes, I see over 16k downloads of 0.74.0 for @react-native/codegen, is it just from the react-native repo?

[cortinico]

All good on my end.
To provide context for everyone: historically we used to bump to 0.X+1 on main after a branch cut just for nightlies reasons. Practically we had unshipped code on main that wouldn't be accessible to nightlies unless we published a bump for a package.

Now that we have @nightly version for each of the monorepo package, we can safely remove the need to bump I believe.

Happy to hear if there are concerns

[Saadnajmi]

In general I am supportive of nightlies using nightly versions, and stable versions using stable versions. The 0.X+1 system I wasn't much of a fan of (I felt that 0.xx should always be published from 0.xx-stable, not once from main, then subsequently from 0.xx-stable). This was enough that I wanted to look into using Yarn 4 + workspaces to see if we could do something like React Native macOS publishing their own nightly mono repo packages.

That being said, I think it will introduce an extra step/complication on our end. React Native macOS re-uses most of the most of the mono repo packages from React Native (with the exception of @react-native-mac/virtualized-list). There's no guarantees our nightly commit matches up with yours, since I'm pretty sure they're based on commit hashes (which are rarely if ever in sync). If React Native Core nightlies will stop using 0.xx versions for its mono repo packages, then we will most likely have to publish our own versions of every monorepo package. They would be identical in everything but name.. but now we have @react-native-mac/codegen floating around where it used to be an active goal to not need a separate package.

I think React Native macOS publishing nightlies for all mono repo packages may be possible, and perhaps a better long term solution to ensure that our code is actually in sync in between itself. A second question becomes whether we should do the same for stable releases, or just re-use the React Native Core ones as we currently do. I don't know I have a good answer there. I would probably want to keep the same system for both nightlies and stable releases for simplicities' sake.

[lunaleaps]

To clarify this part

If React Native Core nightlies will stop using 0.xx versions for its mono repo packages, then we will most likely have to publish our own versions of every monorepo package.

Today, the process of publishing a nightly react-native will also publish all the monorepo packages and will use those versions. If I'm understanding the above statement correctly, the nightly react-native does not use 0.xx versions for monorepo packages.

❯ npm view react-native@0.74.0-nightly-20240115-0c7008f28 dependencies
{
  '@jest/create-cache-key-function': '^29.6.3',
  '@react-native-community/cli': '13.0.0',
  '@react-native-community/cli-platform-android': '13.0.0',
  '@react-native-community/cli-platform-ios': '13.0.0',
  '@react-native/assets-registry': '0.74.0-nightly-20240115-0c7008f28',
  '@react-native/community-cli-plugin': '0.74.0-nightly-20240115-0c7008f28',
  '@react-native/codegen': '0.74.0-nightly-20240115-0c7008f28',
  '@react-native/gradle-plugin': '0.74.0-nightly-20240115-0c7008f28',
  '@react-native/js-polyfills': '0.74.0-nightly-20240115-0c7008f28',
  '@react-native/normalize-colors': '0.74.0-nightly-20240115-0c7008f28',
  '@react-native/virtualized-lists': '0.74.0-nightly-20240115-0c7008f28',
  'abort-controller': '^3.0.0',

Regarding your points of how this would complicate for macOS fork..to clarify, the complication is just for nightly publishes of react-native-macos? Because today you use the 0.74.0 versions (aka the main publishes) of these monorepo packages in your nightly? Or is there somewhere else you also use these?

If that is the case, then the 0.74.0 publishes of monorepo packages are almost equivalent to the stable publishes of those monorepo publishes no -- because they're published at the time we cut 0.73 RC? Could the react-native-macos nightlies use those instead? So for right now that would be ^0.73.0

[Saadnajmi]

Actually, it seems I am wrong. I took a look at our latest published nightly's code: https://www.npmjs.com/package/react-native-macos/v/0.74.0-nightly-20240115-01efe8351?activeTab=code

    "@react-native/assets-registry": "0.74.0-nightly-20240115-01efe8351",
    "@react-native/community-cli-plugin": "0.74.0-nightly-20240115-01efe8351",
    ...

The commit hash of the version isn't coming from React Native Core, but the latest commit on React Native macOS: microsoft/react-native-macos@01efe83

Those package versions don't exist, and actually our nightlies are currently broken, in exactly the way I thought they might 😅. Similarly, react-native-test-app already caught this and temporarily disabled testing our nightlies: microsoft/react-native-test-app#1772 . Fun, I have things to fix 😀

If that is the case, then the 0.74.0 publishes of monorepo packages are almost equivalent to the stable publishes of those monorepo publishes no -- because they're published at the time we cut 0.73 RC? Could the react-native-macos nightlies use those instead? So for right now that would be ^0.73.0

Wait, I thought that the N+1 (aka, 0.74.3, etc) publishes were going away, Instead we would have only packages with night versions (0.74-commit hash). Are you suggesting that our nightlies use the latest nightly RN published, thinking they're nearly identical?

[lunaleaps]

Wait, I thought that the N+1 (aka, 0.74.3, etc) publishes were going away, Instead we would have only packages with night versions (0.74-commit hash). Are you suggesting that our nightlies use the latest nightly RN published, thinking they're nearly identical?

Yes the N+1 publishes are going away, and yes there will still be nightly versions (0.74-commit-hash). Hmm so I originally was suggesting 0.73.x for your nightlies but thinking about it more, I'm not totally clear if we can make the assumption those will be compatible with your nightlies.

My line of thinking was when we do cut 0.73 RC, we have a step to publish the monorepo packages if there have been changes. So for a given monorepo package, 0.73.0 was published when 0.72 was cut, if we made any changes on main since then, we'd publish 0.73.1, etc. ... until we're ready to cut 0.73 -- let's call this version 0.73.Y for a given monorepo package.

In present day, where we still do N+1 publishes, I think 0.73.Y would be identical to 0.74.0. The question is if we do picks on the 0.73-stable branch and publish as 0.73.(Y+1), would those be consumable by your nightlies?

---

As another approach, another proposal we have for releases is to start picking nightlies as our rc.0. This would involve taking a version like 0.74.0-nightly-20240115-0c7008f28 and from OSS usage and release testing, we'd identify that this version is stable and re-publish this version as 0.74.0-rc.0 for react-native and all its monorepo packages.

If we do this, then nightly react-native-macos could use this version 0.74.0-rc.0.

---

Thinking about this more, I think I don't understand how react-native-macos syncs with react-native versions. Like how would you classify react-native-macos is upgraded to 0.73, etc.? Or is there a regular commit sync? If that was the case, could we pick nightlies published just before that commit sync?

[Saadnajmi]

For React Native macOS, we basically choose a commit, git pull up that commit, and fix all the merge conflicts. When a stable branch is cut, we're careful to merge to that specific commit, and then do our cut there too. For our release pipeline, I try to also re-use as many of the scripts that React Native Core uses (prepare-package-for-release.js, setting the build-type, etc..). For future releases, we've been thinking about moving to a completely separate release process, as having our release process tied to upstream (but running on different CI providers / cadences) has caused lots of issues.

While your first suggestion makes sense, (0.73.y is probably identical to 0.74.0), I think for nightlies I'd rather steer away from "probably identical and consistent" to "systematically, always consistent". That can only happen (as far as my thinking goes right now..) if we published @react-native-mac/` versions of all the nightly packages, so I think for me I'll just have to decide which approach causes least risk. For Hermes for example, we've already decided to just use the latest stable prebuilt of Hermes from upstream for our fork rather than rebuild it (see microsoft/react-native-macos#2014). Technically not systematically-always-consistent, but probably fine.

For picking a nightly as an rc.0, that makes sense. I don't think that has much bearing on us, RNM historically hasn't released RCs because we're usually still merging up to the latest stable release. Maybe that changes now.

To reiterate, overall I am supportive of the change in the RFC, and the RNM team will regardless have to rethink how we do nightlies. They were already broken, so that was going to happen eventually anyway :D

[lunaleaps]

Sounds good, thanks @Saadnajmi for clarifying macOS usage of nightlies. I'll make this change then for 0.74 -- which really just means a process change. This means we won't have monorepo packages at 0.75.0 until we actually cut 0.75.