Chapter 6
Continuous Integration and Collaboration

A recurring theme of this book has been the power of automation to improve your workflow. When properly applied, tools like ESLint and Jest greatly increase the chances that you’ll catch mistakes in your code long before that code has a chance to go into production. But your workflow is just that: yours. When you’re working as part of a team, or maintaining an open source project, how do you extend the power of automation to your collaborators?

One answer is good old-fashioned documentation: “Please run the tests before submitting a patch.” But that leaves the door open for human error. A better solution is to offload such quality control checks to a server, away from the personalized environments of developer machines. This technique has become known as continuous integration (CI).

Continuous integration takes weight off of your shoulders as a project maintainer by allowing you to automate tasks you’d otherwise have to take on yourself. The CI server can tell potential contributors not only whether their patches pass the project’s tests, but also how much those changes affect test coverage, compiled asset size, and any other metrics you care about.

Adding a CI server is a solid first step for project automation. You can go further by adding scripts to your contributors’ development workflows and providing live documentation for developers to play with. Taking the time to set up all of these support tools will pay dividends by making your project’s requirements crystal-clear to potential contributors and streamlining the process of reviewing their patches.

In this chapter, you’ll learn to set up the popular Travis CI service to run the tests for the test-driven-carousel project. You’ll also learn how to use Husky to add Git hooks to your project to check code before it’s committed, spotting potential problems early. And finally, you’ll generate sleek, interactive documentation for your carousel component with Storybook.