TL;DR
- ESLint や Stylelint などのチェックは開発者のローカル環境でしか動かないので、チーム開発では継続的インテグレーション（CI）で自動化する。
- あわせて、コミット前にチェックする Husky と、Storybook によるドキュメント生成を導入する。
内容
これまで設定した ESLint や Stylelint は、各開発者のローカル環境でしか動かない。チームで作業する場合や OSS プロジェクトを維持する場合、全員にこの環境を強制するのは手間がかかる。そこで、チェックを個々の開発者の環境から切り離す継続的インテグレーション（CI）が欠かせなくなる。方針は「積極的に自動化する」ことである。著者は、より良いプログラマになる道は常にフィードバックを得ることだと述べている。
the path to becoming a better programmer is constant feedback.
フィードバックを常に得るために、積極的に自動化する姿勢を持つことが大事である。
本書では、CI サービスとして Travis CI を使う。CI サーバでは、次のことを確かめられる。
- テストがパスしたか
- テストカバレッジがどれだけ変わったか
- アセットのサイズがどれだけ変わったか
このほか、コードがコミットされる前にチェックして問題を早く見つけるために Husky を導入する。また、Storybook でインタラクティブなドキュメントを生成する。