Please sign in to comment.
Set up experimental builds (#17071)
* Don't bother including `unstable_` in error The method names don't get stripped out of the production bundles because they are passed as arguments to the error decoder. Let's just always use the unprefixed APIs in the messages. * Set up experimental builds The experimental builds are packaged exactly like builds in the stable release channel: same file structure, entry points, and npm package names. The goal is to match what will eventually be released in stable as closely as possible, but with additional features turned on. Versioning and Releasing ------------------------ The experimental builds will be published to the same registry and package names as the stable ones. However, they will be versioned using a separate scheme. Instead of semver versions, experimental releases will receive arbitrary version strings based on their content hashes. The motivation is to thwart attempts to use a version range to match against future experimental releases. The only way to install or depend on an experimental release is to refer to the specific version number. Building -------- I did not use the existing feature flag infra to configure the experimental builds. The reason is because feature flags are designed to configure a single package. They're not designed to generate multiple forks of the same package; for each set of feature flags, you must create a separate package configuration. Instead, I've added a new build dimension called the **release channel**. By default, builds use the **stable** channel. There's also an **experimental** release channel. We have the option to add more in the future. There are now two dimensions per artifact: build type (production, development, or profiling), and release channel (stable or experimental). These are separate dimensions because they are combinatorial: there are stable and experimental production builds, stable and experimental developmenet builds, and so on. You can add something to an experimental build by gating on `__EXPERIMENTAL__`, similar to how we use `__DEV__`. Anything inside these branches will be excluded from the stable builds. This gives us a low effort way to add experimental behavior in any package without setting up feature flags or configuring a new package.
- Loading branch information
Showing with 126 additions and 47 deletions.
- +94 −15 .circleci/config.yml
- +1 −0 .eslintrc.js
- +5 −7 packages/react-dom/src/__tests__/ReactDOMRoot-test.js
- +6 −18 packages/react-dom/src/client/ReactDOM.js
- +1 −1 packages/shared/ReactFeatureFlags.js
- +1 −1 scripts/error-codes/codes.json
- +1 −1 scripts/eslint-rules/__tests__/warning-and-invariant-args-test.internal.js
- +1 −0 scripts/flow/environment.js
- +1 −0 scripts/jest/setupEnvironment.js
- +8 −2 scripts/release/utils.js
- +7 −2 scripts/rollup/build.js
Oops, something went wrong.