Set up experimental builds #17071
Merged
Set up experimental builds #17071
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
ReactDOM: size: 0.0%, gzip: -0.0% Details of bundled changes.Comparing: 75955bf...9977c2c react-dom
|
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.
acdlite
force-pushed
the
experimental-release-channel
branch
from
7687b9e
to
8c4854d
Compare
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.
acdlite
force-pushed
the
experimental-release-channel
branch
8 times, most recently
from
b1b697e
to
f17702d
Compare
acdlite
force-pushed
the
experimental-release-channel
branch
from
f17702d
to
9977c2c
Compare
bvaughn
reviewed
Oct 14, 2019
| @@ -74,6 +100,18 @@ jobs: | |||
| - *run_yarn | |||
| - run: yarn test --maxWorkers=2 | |||
|
|
|||
| test_source_experimental: | |||
There was a problem hiding this comment.
I assume that since we're using parallel containers, this won't actually increase the duration of every CI job? That would not be great.
There was a problem hiding this comment.
The workflows run in parallel, yeah
| @@ -682,9 +671,8 @@ function warnIfReactDOMContainerInDEV(container) { | |||
| if (__DEV__) { | |||
| warningWithoutStack( | |||
| !container._reactRootContainer, | |||
| 'You are calling ReactDOM.%s() on a container that was previously ' + | |||
| 'You are calling ReactDOM.createRoot() on a container that was previously ' + | |||
There was a problem hiding this comment.
I would not expect all fo these conditional names to change, given that we run this test against not-experimental builds as well. Why did they?
There was a problem hiding this comment.
See the first commit.
The method names don't get stripped out of the production bundles
because they are passed as arguments to the error decoder.
Slightly unrelated but I did it this way instead of checking __EXPERIMENTAL__ in the tests. We're probably going to remove the prefixed versions from the stable releases, anyway.
|
@bvaughn I'll do release script changes in a follow-up. The existing |
bvaughn
approved these changes
Oct 14, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 development 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.