Release and its automated processes

This page contains relevant information about automated processes / utilities that can be used in a release cycle.

Finding all packages that have unpublished changes

Use case

1. You want to identify each package with unpublished (on npm) changes and update its version. This can be used in release cycle if you have merged some fixes to *-stable branch.
2. You want to force-bump each public package to the next minor version. This happens usually before release branch cutoff. In this case, please specify release-branch-cutoff argument before executing the script.

How to execute

npm run bump-all-updated-packages or npm run bump-all-updated-packages --release-branch-cutoff

Pseudocode

check that no git changes are present

for each package:
    if package is private -> skip

    if release-branch-cutoff argument is provided:
        bump package version to the next minor
        return

    grep id of the last commit that changed package
    grep id of the last commit that changed version of the package

    if these ids are different:
        bump package version (minor or patch)

commit changes if required

Notes

At the final step you will be asked if you want to commit all these changes. Always select Yes if you want these packages to be published then on CircleCI, because the workflow that does this will check that commit has a tag inside its message.

Publishing an updated package to npm

We have a CircleCI workflow, which runs only on main or stable-* branches.

Pseudocode

for each package:
    if last commit contains version change:
        if this commit has specific message:
            publish package to npm

Notes

This workflow explicitly checks that commit has a specific tag inside its message. This is used to prevent accidental publishes. To create such specific commit you should use script from above.

If you want to bump package version and publish it to npm registry, your version change should be exactly in the last commit. This is because of two things:

1. If multiple commits are merged to main branch at the same time, CircleCI will execute workflows only once on top of the latest commit.
2. To determine that version was changed we evaluate the difference between HEAD and HEAD~1.

Example script output, where no package versions were changed:

Align package versions across monorepo

Use case

You (or someone from release cycle team) have recently used a script to bump versions of updated packages and now these versions are available on npm. You want to align these versions across every package inside monorepo including repo-config and template.

How to execute

npm run align-package-versions

Pseudocode

check that no git changes are present

for each package x:
   for each package y:
       if y has x as dependency:
           validate that y uses the latest version of x

if some changes were made:
   run yarn

Notes

Usually, if this script is executed on main branch, a pull request with the changes should be imported by an engineer from Meta to update yarn lockfiles. This is only if you merging these changes to main branch.

Q&A

Why there are two different scripts to update versions everywhere?

For *-stable branches, there are no yarn workspaces and all packages are specified as direct dependencies, so for instance, if we update @react-native/assets-registry to the next version, we won't be able to run yarn for react-native root package, because updated version is not yet published to npm. This is caused by the nature of the repository and the code structure, which is currently getting reworked as per this RFC.

To avoid this, we first need publish new versions and then update them in consumer packages.