Skip to content

Commit bab24fb

Browse files
authored
Moving docs onto /docs
1 parent 8b01f59 commit bab24fb

File tree

1 file changed

+73
-0
lines changed
  • packages/homepage/content/docs

1 file changed

+73
-0
lines changed
Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
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

Comments
 (0)