Add CodeSandbox CI Config

[CompuIves]

This will enable CodeSandbox CI on the React repo. To have a better idea of what CodeSandbox CI does you can read more about it here: https://u2edh.csb.app/. I recommend merging this PR first before installing the GitHub App, to ensure that all future PRs will work from the get-go.

The gist of it is:

The goal of this app is to make it easier for you to test your library without publishing to npm yet. Since CodeSandbox is already used for bug reports we wanted to make it possible to also test the PR version of your library with the existing bug reports.

In an ideal flow, it would work like this:

1. Someone opens an issue for a bug with a sandbox reproducible
2. Someone opens a fix PR mentioning the issue
3. We build the library from the PR, fork the sandbox repro and install the new library in that sandbox
   This way you will only have to open the generated sandbox to confirm that the fix works. No need to clone, install or test locally.

[sizebot]

No significant bundle size changes to report.

Generated by 🚫 dangerJS against a4e12fd

[eps1lon]

Suggested change

	"buildCommand": "build react/index,react-dom/index",
	"buildCommand": "build --type=UMD,NODE react/index,react-dom/index",

The other bundles won't be published anyway due to the publishDirectory.

[acdlite]

Don't need UMD, though

[acdlite]

Let's do Scheduler, too.

[acdlite]

We already build all the packages and store them as CircleCI artifacts. Is there some way we could leverage those instead of building twice? Then we don't have to worry about them getting out of sync. These are also the same artifacts we publish to npm.

Perhaps by waiting for CircleCI to finish first, and then downloading the tarball from there?

[eps1lon]

I think this will cause the same issue as mui/material-ui#17976 (comment):
react-dom declares a dependency on scheduler with the newly created version but codesandbox thinks this version is on the npm registry.

I guess this applies regardless of whether scheduler is built in the codesandbox CI or not.

[acdlite]

react-dom declares a dependency on scheduler with the newly created version but codesandbox thinks this version is on the npm registry.

The way we handle this with our prerelease builds is we have a post-build step to rewrite the package jsons to update the version numbers to point to each other:

react/scripts/release/utils.js

Lines 192 to 200 in 3497ccc

	// This method is used by both local Node release scripts and Circle CI bash scripts.
	// It updates version numbers in package JSONs (both the version field and dependencies),
	// As well as the embedded renderer version in "packages/shared/ReactVersion".
	// Canaries version numbers use the format of 0.0.0-<sha> to be easily recognized (e.g. 0.0.0-57239eac8).
	// A separate "React version" is used for the embedded renderer version to support DevTools,
	// since it needs to distinguish between different version ranges of React.
	// It is based on the version of React in the local package.json (e.g. 16.6.1-canary-57239eac8).
	// Both numbers will be replaced if the canary is promoted to a stable release.
	const updateVersionsForCanary = async (cwd, reactVersion, version) => {

So then the result looks like:

"name": "react-dom",
"version": "0.0.0-f6b8d31a7",
"dependencies": {
  "loose-envify": "^1.1.0",
  "object-assign": "^4.1.1",
  "prop-types": "^15.6.2",
  "scheduler": "0.0.0-f6b8d31a7"
},
"peerDependencies": {
  "react": "0.0.0-f6b8d31a7"
}

We can do the same in the build script for CodeSandbox CI. (Also this is one of the reasons I wanted to pull from the CircleCI artifacts, so subtle stuff like this stays in sync.)

Seems like it could be a cool feature for CodeSandbox CI to support, too :)

[eps1lon]

Yeah I tried this too but the issue is that codesandbox looks for this version on the npm registry. Unless you publish the PR build to npm codesandbox won't find it. Unless they changed it in the last days.

The key difference is that react-dom is declared in the package.json of the codesandbox as a url not a version string.

[acdlite]

Ah yeah that's exactly the same I issue I ran into when I tried to do a version of this myself. I was using tarball URLs and the top level dependencies loaded fine, but the transitive dependencies didn't because CodeSandbox tried to pull them from npm.

This is a blocker for us being able to use it, unfortunately

[CompuIves]

It should resolve the package with the same version number (regardless of the source, npm or csb), since we use the node file resolver for finding packages. If that's not happening we encountered a bug, I'll take a look at that today!

I really like the idea of version rewriting, I'll take a look at that today as well!

[CompuIves]

I added version rewriting to the CI service, it should go live in a couple hours. This should make it easier for packages that require eachother to resolve eachother.

I also found why we resolve other dependency versions for transitive dependencies, it's interesting, because yarn has the same behaviour as CodeSandbox, but npm resolves them from the tar files. I got it to work locally and in CodeSandbox by using a resolution field, but I like the rewriting of the versions more as it's more transparent (and it feels less fragile).

[CompuIves]

You can see the current version of the PR in action in CodeSandbox CI here:

• PR itself: Add CodeSandbox CI Config CompuIves/react-1#1
• In CI: https://ci.codesandbox.io/status/CompuIves/react-1/pr/1/builds/695

[acdlite]

Thanks so much for this PR, @CompuIves! And for CodeSandbox! Excited to merge this tomorrow

[CompuIves]

Everything should be working as expected now! I'm super excited for this 😄 😄

[acdlite]

Ok let's go! Thank you again!

[acdlite]

I'll need to ask the OSS team at Facebook to approve the GitHub app. But I don't expect that will be an issue :)