Publishing a JavaScript library for public use requires some extra steps. You need to think about how people will use the library. From end users, to contributors your library now has a variety of people outside of yourself potentially making use of the code that you've released into the wild.

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.

This series will guide you through a set of steps to publish a JavaScript open source library.

You might also enjoy [this article about contributing to open source](https://egghead.io/articles/get-started-contributing-to-javascript-open-source).

This is an introduction to the "How to Write a JavaScript Library" in which the scope of the series is presented. You will learn everything you need to know to create a library for JavaScript: set up the [GitHub](https://github.com) repo, publish a module to [npm](https://www.npmjs.com/), set up a test suite with code coverage reporting (using [Karma](http://karma-runner.github.io/), [Mocha](http://mochajs.org/), and [Chai](http://chaijs.com/)), add continuous integration, add ES6 (ES2015) with [Babel](http://babeljs.io/), configure [Webpack](http://webpack.github.io/), and distribute the library as a ["Universal JavaScript"](https://medium.com/@mjackson/universal-javascript-4761051b7ae9) (a.k.a. "Isomorphic JavaScript") module (consumable by both the browser and node).

Introduction to How to Write an Open Source JavaScript Library

In this lesson, you'll learn how to set up a GitHub account, create a new GitHub repository, and connect your local project with that new repository so you have a place to store and collaborate on your library code.

Setting up GitHub

In this lesson, you'll learn how to set up your machine to publish to [npm](https://www.npmjs.com/) 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 `npm init`.

Configuring npm and creating a package.json

Don't reinvent the wheel. We're creating a great library here, but we don't have to write every line of code. Learn how to depend on other libraries while creating your own in this lesson.

Creating the library and adding dependencies

Once you've written some code and you feel good about it, it's time to commit that code and push it up to your GitHub repository for storage and collaboration.

Pushing to GitHub

Putting your code up on GitHub is helpful, but publishing your library to npm makes it even easier for people to use your library. In this lesson, you'll learn how to publish your library and validate that it published correctly.

Publishing to npm

Now that you've released your module to `npm`, it's time to learn how to associate that release with a particular commit on GitHub. In this lesson learn how to create a tag using `git tag` and then how to associate that with a release on GitHub.

Releasing a version to GitHub

When you want to add a new feature, fix a bug, or push out a breaking API change, you need to take Semantic Versioning into account. In this lesson, learn what each number means as well as how to push out a new version of your library.

Releasing a new version to npm

Sometimes you're not quite ready to release a full on version of your open source library to npm. In this lesson, learn how to publish a beta version so people can try it out without tampering with anyone else using your library.

Publishing a beta version

Every dependable library needs to have tests to ensure that you don't push accidental bugs. In this lesson, see how you can set up mocha and chai to start testing your library.

Setting up Unit Testing with Mocha and Chai

Now that you've got everything set up with mocha and chai, it's time to actually write tests. In this lesson you'll learn how to use `describe` and `it` to outline your tests and make sure you don't break your library in the future.

Unit Testing with Mocha and Chai

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.

Automating Releases with semantic-release

Because semantic-release requires a specific message format, it's easier to follow this convention using a tool called commitizen. In this lesson, we'll use it to write our first conventional commit message.

Writing conventional commits with commitizen

In this lesson, we'll add a new feature to our library and use commitizen to generate our commit message that follows the convention for semantic-release to know it needs to bump the minor version.

Committing a new feature with commitizen

Now that we have everything set up with semantic-release and we have a feature commit, let's push that up and watch TravisCI use semantic-release do our library release automatically.

Automatically Releasing with TravisCI

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.

Automatically running tests before commits with ghooks

This lesson will utilize the Istanbul tool to instrument our code for code coverage recording and reporting. We'll use this to make sure that as our library gets new features, we keep track of our coverage and can find places to improve it.

Adding code coverage recording with Istanbul

Now that we have code coverage being reported, let's make sure that nobody commits code which drops code coverage below our standard by adding a `check-coverage` script that utilizes istanbul's built-in `check-coverage` command.

Adding code coverage checking

Now that we're keeping track of our coverage, let's upload our reports to a third party service so we can track our stats over time. In this lesson we'll show how easy it is to upload our stats to codecov.io.

Add code coverage reporting

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](http://shields.io/)

Adding badges to your README

Writing the code in the next version of JavaScript can really simplify the development of a library. In this lesson, learn how to create a build which uses the BabelJS transpiler to enable you to write your code using ES6 (aka ES2015) syntax.

Adding ES6 Support

By adding ES6 support to our source code, we need to add that same support to our tests so we can consume that synatx. This is quite easy with the `--compilers` flag for `Mocha`.

Adding ES6 Support to Tests using Mocha and Babel

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 `.travis.yml` file.

Limit Built Branches on Travis

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`](http://webpack.github.io/) to create a [`UMD`](https://github.com/umdjs/umd) (Universal Module Definition) build of our module so users can consume it in a browser.

How to Write an Open Source JavaScript Library

Instructor

Course Content