Automated incremental React releases

[bvaughn]

This ticket covers the changes/additions we would need to make to our existing release scripts to support automatically publishing canaries from master.

Changes to CI scripts

• Create a canary from current Git branch and revision #14244: Update CI scripts and scripts/release/build.js to share code for building and generating artifacts. (There's a lot of redundancy now.)
• Create a canary from current Git branch and revision #14244: Auto-generate a checksum file and add it to each NPM package (as well as the files array in the package.json). This will enable us to later verify that that a specific package version corresponds with a specific Git revision to help ensure that we don't accidentally publish incompatible sibling packages.
• Create a canary from current Git branch and revision #14244: Auto-generate a unique version number based on the Git revision that can be used for a canary (like this).
• Save CI-built node_modules as build artifacts #14205: Circle CI already builds all of our packages and runs tests again both source and the built modules. This is most of what our build script currently does. We should go ahead and save the resulting builds to Circle CI so that we can just download and publish them as-is.

Changes to local scripts

• Download Circle CI artifact and prepare canary release #14225: Create a script to prepare a canary release from a CI artifact.
  • Require inputs: Circle CI build identifier (e.g. 12639).
  • It should download and extract the artifact to build/node_modules
• Create a canary from current Git branch and revision #14244: Create a script tp create a canary release from the current Git branch and revision.
  • Resulting output should be the same as the canary release script.
• Promote a canary from NPM to be a stable release #14255: Create a script tp prepare a stable release from a published canary.
  • Promote a canary from NPM to be a stable release #14255: Require inputs: NPM version number of a published canary release.
  • Promote a canary from NPM to be a stable release #14255: It should scan the local packages directory to determine the list of non-private packages, and then check out the canary version of each package to build/node_modules.
  • Promote a canary from NPM to be a stable release #14255: It should prompt for a version number for each package. (By default, it could fill in the latest major+minor by querying NPM.) This should be done up front because of inter-package dependencies (e.g. react depends on scheduler).
  • Promote a canary from NPM to be a stable release #14255: It should replace the canary version number (in both package.json and in the source for renderers) with the specified version. It should also replace version numbers for dependencies/peerDependencies.
  • Promote a canary from NPM to be a stable release #14255: It should restore the proper version constraints (e.g. "x.x.x" vs "^x.x.x") based on source packages.
• Publish a local release (canary or stable) to NPM #14260: Update the existing publish script.
  • Publish a local release (canary or stable) to NPM #14260: Require inputs: OTP token and a list of NPM tags (e.g. --tags=latest, --tags=latest,next).
  • Publish a local release (canary or stable) to NPM #14260: It should prompt the release engineer to update the changelog.
  • Publish a local release (canary or stable) to NPM #14260: It should add a Git tag for the revision the canary release was originally created from (using build-info.json).
  • Publish a local release (canary or stable) to NPM #14260: It should publish each package to NPM with the specified version number and tag.
  • Publish a local release (canary or stable) to NPM #14260: The script will download and stage updated error codes after publishing a stable release (aka --tags latest).
  • Publish a local release (canary or stable) to NPM #14260: The script should also support basic "resume" functionality by checking to each package to see if it has already been published before publishing it (and skipping it if so).
  • Publish a local release (canary or stable) to NPM #14260: The script should auto-update package JSON and shared/ReactVersion to match published content after a stable release.
• Publish a local release (canary or stable) to NPM #14260: Remove the existing build script once it's no longer needed.
• Publish a local release (canary or stable) to NPM #14260: Update [README](https://github.com/facebook/react/blob/master/scripts/release/README.md with overview of each executable script.

Nice to have

• Visually identify canary builds react-devtools#1239: DevTools should be able to detect this a canary version (using a regex?) and visually signify that the via a new icon or something.
• Add progress bars to longer running async release tasks #14322: Store local rolling average for how long the "build" step takes for long steps (e.g. create-canary) and show a progress bar with estimated time remaining.
• Add basic release script snapshot test #14280: Create snapshot tests for the new promote script above that runs each in a "dry run" mode and compares the resulting package.json content. (We could use this to promote a known canary version to a specific release version in order to regression test changes to the build script in the future.)
• Automatically create the GitHub release for stables (see API docs).

Open questions

• When do we update scripts/error-codes/codes.json? Does this file need to be generated by CI and stored as an artifact as well? Should the publish script clone the React repo, checkout the version specified by build-info.json, and run the error codes update script as part of publishing?
• How do we want to version react-cache? It is currently marked private so the release scripts will ignore it, but if we made it public– the current version schema would cause problems. Our release script assumes that packages will either be unstable releases or lock-synced with the main React version but react-cache is currently tagged as version 2.0. Solution: Skip this package for now (since it's private) and stick with a 2.x version scheme.

[bvaughn]

Done enough for now! Let's revisit when GitHub Actions are supported for public repos!