From Github and npm, to releasing beta versions, semantic versioning, code coverage, continuous integration, and providing your library with a solid set of unit tests, there are a ton of things to learn.
You might also enjoy this article about contributing to open source.
In this lesson, you'll learn how to set up your machine to publish to npm so people can install your library. You'll configure some helpful defaults and use those to create a
package.json file for your project using
There are so many repeated steps when releasing a new version of a library. The tool semantic-release automates this process by pushing off the responsibility of your releases to continuous integration. Trust us, this will change your workflow for the better.
Wouldn't it be nice if everyone ran the tests before committing code? With ghooks, you can automatically add a githook when dependencies are installed which will allow you to define common scripts to be run at various points during git actions (like committing). In this lesson, we'll add a githook for running the tests before we commit code to make sure we don't commit anything that breaks the tests.
It's nice to know the status of a project. Adding badges to your readme gives first-timers and old-timers an at-a-glance peek into the status of your project. In this lesson, we'll add several badges using shields.io
By default, Travis will build all branches, tags, and Pull Requests. Because we're building our master branch before we release, we don't need Travis building our releases. Also, we don't care to have Travis build all the branches. So we're going to limit Travis to only build our master branch and Pull Requests by configuring travis via our
Currently, our library is being distributed as a CommonJS module, but we should support the browser as well. In this lesson, we're going to use
webpack to create a
UMD (Universal Module Definition) build of our module so users can consume it in a browser.