|
| 1 | +--- |
| 2 | +title: CI |
| 3 | +authors: ['Ives van Hoorne'] |
| 4 | +description: |
| 5 | + Here's what CodeSandbox CI is, how it will benefit you as a library maintainer, and how to set it up for your library. |
| 6 | +--- |
| 7 | + |
| 8 | +## What is CodeSandbox CI? |
| 9 | + |
| 10 | +CodeSandbox CI is a [GitHub app](https://github.com/apps/codesandbox) that you can install in your repository. The app is responsible for building your library. Whenever a Pull Request is opened it builds a version of the library from that PR. This is published to our registry, so you can immediately test the library in CodeSandbox or locally without publishing to nom or elsewhere. |
| 11 | + |
| 12 | +While Client Sandboxes have faster previews and offline availability, they lack |
| 13 | +in configurability. Container Sandboxes take longer to start up, but effectively |
| 14 | +behave much like a local development environment, allowing you to customize your |
| 15 | +build tools, set up servers to listen to incoming requests, etc. |
| 16 | + |
| 17 | +## Why do I want this? |
| 18 | + |
| 19 | +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. |
| 20 | + |
| 21 | +## How does it work? |
| 22 | +A typical workflow might look like this: |
| 23 | +- Someone opens an issue for a bug with a sandbox reproducible |
| 24 | +- Someone opens a fix PR mentioning the issue |
| 25 | +- We build the library from the PR, fork the sandbox repro and install the new library in that sandbox. |
| 26 | +This way you will only have to open the generated sandbox to confirm that the fix works with no need to clone, install or test locally. |
| 27 | + |
| 28 | +## How do I set this up? |
| 29 | +For most libraries, the only thing you need to do is install this [GitHub App](https://github.com/apps/codesandbox). In some cases you might need to do some configuration, an example of this is for monorepos. You can configure your library by creating a file called `ci.json` in a folder called `.codesandbox` (`.codesandbox/ci.json`) in the root of your repo. An example PR can be found [here](https://github.com/facebook/react/pull/17175). |
| 30 | + |
| 31 | +## Configuration |
| 32 | +You can configure how your projects build on CodeSandbox CI by creating a file called `ci.json` in a folder called `.codesandbox` in the root of your repository. |
| 33 | + |
| 34 | +### Configuration Format |
| 35 | +These are all the configuration options you can set. They are all optional. |
| 36 | + |
| 37 | +``` |
| 38 | +{ |
| 39 | + // which script in package.json to run to install instead of `npm ci` or `yarn install`, |
| 40 | + // can be `false` if you want to skip this step |
| 41 | + "installCommand": "install", |
| 42 | + // which script in package.json to run to build, |
| 43 | + // can be `false` if you want to skip this step |
| 44 | + "buildCommand": "build", |
| 45 | + // if you have a monorepo, put the paths of the packages here. We'll infer the package names. |
| 46 | + // globs are supported |
| 47 | + "packages": ["packages/react", "packages/react-dom"], |
| 48 | + // if you don't publish from the package directory, specify per dependency |
| 49 | + // where the contents of the built dependency are. These files will be uploaded |
| 50 | + // to our registry |
| 51 | + "publishDirectory": { |
| 52 | + "react": "build/node_modules/react" |
| 53 | + "react-dom": "build/node_modules/react-dom" |
| 54 | + }, |
| 55 | + // a list of sandboxes that you want generated for a PR, if this list |
| 56 | + // is not set we will default to `vanilla`. The built library will automatically |
| 57 | + // be installed in the fork of these sandboxes in the place of the library. So if |
| 58 | + // you have a sandbox with `lodash`, and you built `lodash` and `vue`, we will only |
| 59 | + // replace `lodash` with the built version. |
| 60 | + "sandboxes": ["vanilla", "new", "github/reduxjs/redux/tree/master/examples/todomvc"] |
| 61 | +} |
| 62 | +``` |
| 63 | + |
| 64 | +### Monorepo Example |
| 65 | +Monorepos are quite common, here's an example configuration for a monorepo: |
| 66 | +``` |
| 67 | +{ |
| 68 | + "packages": ["./", "packages/vue-template-compiler"], |
| 69 | +} |
| 70 | +``` |
| 71 | +This builds two libraries: `vue`, which is in the root of the repository, and `vue-template-compiler`, which resides in the `packages` folder. |
| 72 | + |
| 73 | +We handle auto linking of these dependencies, this means that we rewrite the dependencies to the newly built versions of CodeSandbox CI. In this example, `vue` uses `vue-template-compiler`, so we've updated `package.json` of `vue` to point to our built `vue-template-compiler`. |
0 commit comments