1. # React Release Scripts
    
  2. 
    
  3. This document describes how to prepare and publish a release manually, using the command line.
    
  4. 
    
  5. However, most of our releases are actually *prereleases* that get continuously shipped via CI. Our automated prerelease channels are preferred whenever possible, because if they accidentally break, it won't affect production users.
    
  6. 
    
  7. Before proceeding, consider your motivation:
    
  8. 
    
  9. - **"I want to share experimental features with collaborators."** After your code lands in GitHub (behind an experimental feature flag), it will be automatically published via CI within the next weekday. So usually, all you have to do is wait.
    
  10. - **"But I want to publish it now!"** You can [trigger the CI job to run automatically](#trigger-an-automated-prerelease).
    
  11. - **"I want to publish a stable release with a real version number"** Refer to the ["Publishing a Stable Release"](#publishing-a-stable-release) section. If this is your first time running a stable release, consult with another team member before proceeding.
    
  12. - **"I have some special use case that's not explicitly mentioned here."** Read the rest of this document, and consult with another team member before proceeding.
    
  13. 
    
  14. # Process
    
  15. 
    
  16. If this is your first time running the release scripts, go to the `scripts/release` directory and run `yarn` to install the dependencies.
    
  17. 
    
  18. The release process consists of several phases, each one represented by one of the scripts below.
    
  19. 
    
  20. A typical release cycle goes like this:
    
  21. 1. When a commit is pushed to the React repo, [Circle CI](https://circleci.com/gh/facebook/react/) will build all release bundles and run unit tests against both the source code and the built bundles.
    
  22. 2. Each weekday, an automated CI cron job publishes prereleases to the `next` and `experimental` channels, from tip of the main branch.
    
  23.    1. You can also [trigger an automated prerelease via the command line](#trigger-an-automated-prerelease), instead of waiting until the next time the cron job runs.
    
  24.    2. For advanced cases, you can [**manually prepare and publish to the `next` channel**](#publishing-release) using the [`prepare-release-from-ci`](#prepare-release-from-ci) and [`publish`](#publish) scripts; or to the [**`experimental` channel**](#publishing-an-experimental-release) using the same scripts (but different build artifacts).
    
  25. 3. Finally, a "next" release can be [**promoted to stable**](#publishing-a-stable-release)<sup>1</sup> using the [`prepare-release-from-npm`](#prepare-release-from-npm) and [`publish`](#publish) scripts. (This process is always manual.)
    
  26. 
    
  27. The high level process of creating releases is [documented below](#process). Individual scripts are documented as well:
    
  28. * [`build-release-locally`](#build-release-locally): Build a release locally from the checked out source code.
    
  29. * [`prepare-release-from-ci`](#prepare-release-from-ci): Download a pre-built release from CI.
    
  30. * [`prepare-release-from-npm`](#prepare-release-from-npm): Prepare an NPM "next" release to be published as a "stable" release.
    
  31. * [`publish`](#publish): Publish the downloaded (or prepared) release to NPM.
    
  32. 
    
  33. <sup>1. [**Creating a patch release**](#creating-a-patch-release) has a slightly different process than a major/minor release.</sup>
    
  34. 
    
  35. ## Trigger an Automated Prerelease
    
  36. 
    
  37. If your code lands in the main branch, it will be automatically published to the prerelease channels within the next weekday. However, if you want to immediately publish a prerelease, you can trigger the job to run immediately:
    
  38. 
    
  39. ```sh
    
  40. yarn publish-prereleases
    
  41. ```
    
  42. 
    
  43. This will grab the most recent revision on the main branch and publish it to the Next and Experimental channels.
    
  44. ## Publishing Without Tags
    
  45. 
    
  46. The sections below include meaningful `--tags` in the instructions. However, keep in mind that **the `--tags` arguments is optional**, and you can omit it if you don't want to tag the release on npm at all. This can be useful when preparing breaking changes.
    
  47. 
    
  48. ## Publishing Next
    
  49. 
    
  50. "Next" builds are meant to be lightweight and published often. In most cases, they can be published using artifacts built by Circle CI.
    
  51. 
    
  52. To prepare a build for a particular commit:
    
  53. 1. Choose a commit from [the commit log](https://github.com/facebook/react/commits/main).
    
  54. 2. Copy the SHA (by clicking the 📋 button)
    
  55. 5. Run the [`prepare-release-from-ci`](#prepare-release-from-ci) script with the SHA <sup>1</sup> you found:
    
  56. ```sh
    
  57. scripts/release/prepare-release-from-ci.js -r stable --commit=0e526bc
    
  58. ```
    
  59. 
    
  60. Once the build has been checked out and tested locally, you're ready to publish it:
    
  61. ```sh
    
  62. scripts/release/publish.js --tags next
    
  63. ```
    
  64. 
    
  65. <sup>1: You can omit the `commit` param if you just want to release the latest commit as to "next".</sup>
    
  66. 
    
  67. ## Publishing an Experimental Release
    
  68. 
    
  69. Experimental releases are special because they have additional features turned on.
    
  70. 
    
  71. The steps for publishing an experimental release are almost the same as for publishing a "next" release except for the release channel (`-r`) flag.
    
  72. 
    
  73. ```sh
    
  74. scripts/release/prepare-release-from-ci.js -r experimental --commit=0e526bc
    
  75. ```
    
  76. 
    
  77. Once the build has been checked out and tested locally, you're ready to publish it. When publishing an experimental release, use the `experimental` tag:
    
  78. 
    
  79. ```sh
    
  80. scripts/release/publish.js --tags experimental
    
  81. ```
    
  82. 
    
  83. ## Publishing a Stable Release
    
  84. 
    
  85. Stable releases should always be created from the "next" channel. This encourages better testing of the actual release artifacts and reduces the chance of unintended changes accidentally being included in a stable release.
    
  86. 
    
  87. To prepare a stable release, choose a "next" version and run the [`prepare-release-from-npm`](#prepare-release-from-npm) script <sup>1</sup>:
    
  88. 
    
  89. ```sh
    
  90. scripts/release/prepare-release-from-npm.js --version=0.0.0-241c4467e-20200129
    
  91. ```
    
  92. 
    
  93. This script will prompt you to select stable version numbers for each of the packages. It will update the package JSON versions (and dependencies) based on the numbers you select.
    
  94. 
    
  95. Once this step is complete, you're ready to publish the release:
    
  96. 
    
  97. ```sh
    
  98. scripts/release/publish.js --tags latest
    
  99. 
    
  100. # Or, if you want to bump "next" as well:
    
  101. scripts/release/publish.js --tags latest next
    
  102. ```
    
  103. 
    
  104. After successfully publishing the release, follow the on-screen instructions to ensure that all of the appropriate post-release steps are executed.
    
  105. 
    
  106. <sup>1: You can omit the `version` param if you just want to promote the latest "next" candidate to stable.</sup>
    
  107. 
    
  108. ## Creating a Patch Release
    
  109. 
    
  110. Patch releases should always be created by branching from a previous release. This reduces the likelihood of unstable changes being accidentally included in the release.
    
  111. 
    
  112. Begin by creating a branch from the previous git tag<sup>1</sup>:
    
  113. 
    
  114. ```sh
    
  115. git checkout -b 16.8.3 v16.8.2
    
  116. ```
    
  117. 
    
  118. Next cherry pick any changes from main that you want to include in the release:
    
  119. 
    
  120. ```sh
    
  121. git cherry-pick <commit-hash>
    
  122. ```
    
  123. 
    
  124. Once you have cherry picked all of the commits you want to include in the release, push your feature branch and create a Pull Request (so that Circle CI will create a build):
    
  125. 
    
  126. ```sh
    
  127. git push origin 16.8.3
    
  128. ```
    
  129. 
    
  130. Once CI is complete, follow the regular [**next**](#publishing-release) and [**promote to stable**](#publishing-a-stable-release) processes.
    
  131. 
    
  132. <sup>1: The `build-info.json` artifact can also be used to identify the appropriate commit (e.g. [unpkg.com/[email protected]/build-info.json](https://unpkg.com/[email protected]/build-info.json) shows us that react version 16.8.3 was created from commit [`29b7b775f`](https://github.com/facebook/react/commit/29b7b775f)).</sup>
    
  133. 
    
  134. # Scripts
    
  135. 
    
  136. ## `build-release-locally`
    
  137. Creates a "next" build from the current (local) Git revision.
    
  138. 
    
  139. **This script is an escape hatch.** It allows a release to be created without pushing a commit to be verified by Circle CI. **It does not run any automated unit tests.** Testing is solely the responsibility of the release engineer.
    
  140. 
    
  141. Note that this script git-archives the React repo (at the current revision) to a temporary directory before building, so **uncommitted changes are not included in the build**.
    
  142. 
    
  143. #### Example usage
    
  144. To create a build from the current branch and revision:
    
  145. ```sh
    
  146. scripts/release/build-release-locally.js
    
  147. ```
    
  148. 
    
  149. ## `prepare-release-from-ci`
    
  150. Downloads build artifacts from Circle CI in preparation to be published to NPM as either a "next" or "experimental" release.
    
  151. 
    
  152. All artifacts built by Circle CI have already been unit-tested (both source and bundles) but these candidates should **always be manually tested** before being published. Upon completion, this script prints manual testing instructions.
    
  153. 
    
  154. #### Example usage
    
  155. To prepare the artifacts created by Circle CI for commit [0e526bc](https://github.com/facebook/react/commit/0e526bc) you would run:
    
  156. ```sh
    
  157. scripts/release/prepare-release-from-ci.js --commit=0e526bc -r stable
    
  158. ```
    
  159. 
    
  160. ## `prepare-release-from-npm`
    
  161. Checks out a "next" release from NPM and prepares it to be published as a stable release.
    
  162. 
    
  163. This script prompts for new (stable) release versions for each public package and updates the package contents (both `package.json` and inline version numbers) to match. It also updates inter-package dependencies to account for the new versions.
    
  164. 
    
  165. "Next" releases have already been tested but it is still a good idea to **manually test and verify a release** before publishing to ensure that e.g. version numbers are correct. Upon completion, this script prints manual testing instructions.
    
  166. 
    
  167. #### Example usage
    
  168. To promote the "next" release `0.0.0-241c4467e-20200129` (aka commit [241c4467e](https://github.com/facebook/react/commit/241c4467e)) to stable:
    
  169. ```sh
    
  170. scripts/release/prepare-release-from-npm.js --version=0.0.0-241c4467e-20200129
    
  171. ```
    
  172. 
    
  173. ## `publish`
    
  174. Publishes the current contents of `build/node_modules` to NPM.
    
  175. 
    
  176. This script publishes each public package to NPM and updates the specified tag(s) to match. **It does not test or verify the local package contents before publishing**. This should be done by the release engineer prior to running the script.
    
  177. 
    
  178. Upon completion, this script provides instructions for tagging the Git commit that the package was created from and updating the release CHANGELOG.
    
  179. 
    
  180. **Specify a `--dry` flag when running this script if you want to skip the NPM-publish step.** In this event, the script will print the NPM commands but it will not actually run them.
    
  181. 
    
  182. #### Example usage
    
  183. To publish a release to NPM as both `next` and `latest`:
    
  184. ```sh
    
  185. scripts/release/publish.js --tags latest next
    
  186. ```