1 | # Chromatic CLI
|
2 |
|
3 | Publishes your Storybook to Chromatic and kicks off tests if they're enabled.
|
4 |
|
5 | <img width="100%" src="https://user-images.githubusercontent.com/321738/82901859-d820ec80-9f5e-11ea-81e7-78d494c103ad.gif" alt="">
|
6 |
|
7 | <a href="https://www.npmjs.com/package/chromatic">
|
8 | <img src="https://badgen.net/npm/v/chromatic" alt="Published on npm">
|
9 | </a>
|
10 | <a href="https://www.chromatic.com/builds?appId=5d67dc0374b2e300209c41e7">
|
11 | <img src="https://badgen.net/badge/tested%20with/chromatic/fc521f" alt="Tested with Chromatic">
|
12 | </a>
|
13 |
|
14 | ## Documentation
|
15 |
|
16 | 👉 See the [Chromatic CLI docs](https://www.chromatic.com/docs/cli).
|
17 |
|
18 | ## Contributing
|
19 |
|
20 | Contributions of any kind are welcome! We're available to chat via the Intercom widget on the documentation site.
|
21 |
|
22 | ### Compatibility & versioning
|
23 |
|
24 | Compatibility is guaranteed between this package and Chromatic like so:
|
25 |
|
26 | - Production Chromatic ensures it’s compatible with what’s on npm
|
27 | - What's on the master branch is equal to what's published on npm
|
28 | - This package ensures it’s compatible with production Chromatic
|
29 |
|
30 | To facilitate upgrading in the future, removing and adding features, this is the process:
|
31 |
|
32 | - Any new features will have to be on Chromatic production before they could be used in this package
|
33 | - We can add feature flags to be able to test new functionality
|
34 | - Chromatic production can not remove any features this package depends on until after the usage has been removed from this package in addition to a grace period to allow users to upgrade
|
35 |
|
36 | ### Publishing a new version to npm
|
37 |
|
38 | Before publishing, make sure you've done the following:
|
39 |
|
40 | - `yarn build`
|
41 | - Updated CHANGELOG.md
|
42 | - Committed and pushed everything
|
43 | - Decide on the proper semver bump (major/minor/patch)
|
44 |
|
45 | #### Doing a `canary` or `next` release
|
46 |
|
47 | We have two types of pre-releases: `canary` and `next`. `canary` releases are intended for development purposes and should not be used in production, as they may only work against a staging or dev environment. `next` releases should be valid, working releases that can potentially be used by early adopters of new features, for example to handle a support request.
|
48 |
|
49 | > As a consumer, **you should not specify a tag** (e.g. `chromatic@next`) in your package dependencies, but rather a specific version number (e.g. `chromatic@5.6.2-next.0`). Otherwise you'll end up with a broken build when we remove or update the tag.
|
50 |
|
51 | For the first `canary` (or `next`) release, bump the version like so (depending on the semver bump):
|
52 |
|
53 | ```sh
|
54 | npm version <premajor|preminor|prepatch> --preid canary
|
55 | ```
|
56 |
|
57 | For consecutive `canary` releases on the same version:
|
58 |
|
59 | ```sh
|
60 | npm version prerelease --preid=canary
|
61 | ```
|
62 |
|
63 | Then push and publish:
|
64 |
|
65 | ```sh
|
66 | git push --follow-tags
|
67 | npm publish --tag canary
|
68 | ```
|
69 |
|
70 | Make sure to replace `canary` with `next` if appropriate.
|
71 |
|
72 | #### Doing a `latest` release
|
73 |
|
74 | A final release is automatically tagged `latest` by npm.
|
75 |
|
76 | ```sh
|
77 | npm version <major|minor|patch>
|
78 | git push --follow-tags
|
79 | npm publish
|
80 | yarn publish-action
|
81 | ```
|
82 |
|
83 | And finally, remove the `canary` and/or `next` tag, if any:
|
84 |
|
85 | ```
|
86 | npm dist-tag rm chromatic canary
|
87 | ```
|
88 |
|
89 | This ensures we can safely do a new `canary` or `next` release later, without anyone getting an unexpected update.
|