Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    Automating Releases with semantic-release


    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.



    Become a Member to view code

    You must be a Pro Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    orLog In




    There are a couple of repeated steps when releasing a new version of a library. First you have to develop the new feature or the bug fix, and then you have to commit that and you have to tag that commit, and you have to publish it and you push it up to GitHub.

    There are a lot of different steps, and as programmers we don't like to repeat ourselves, so there's a tool that was developed called semantic release that makes releasing new versions of your software super, super easy. We're going to do that now with our library, Star Wars names.

    We'll run npm install -g semantic-release-cli. Now, with that installed, let's go ahead and run semantic-release-cli setup. This is going to take us through a prompt. Our GitHub repository is not private, with a capital N there, that's the default, so we'll just hit enter.

    Our npm repository or registry is just the normal one, so I'll go with the default there. It read my npm username and my npm email. It got my GitHub username, and now I'm going to choose what continuous integration service I'm using.

    The way that semantic release works is that it will actually release your software or your library during continuous integration. We haven't set up any continuous integration, but semantic release will actually set it up for us and will initialize things for us.

    We're going to stick with Travis CI. If you don't want to use Travis CI, you want to use Snap or Codeship or something else, then you can just print the tokens and then you can use those and set those in your continuous integration. We'll go ahead and stick with Travis CI.

    What semantic release is doing is it's creating a travis job for our library and adding a couple of things to our project. For us, we're just going to stick with a single node version in our travis.yml, and now let's go ahead and look at our project.

    There are a couple of new things in here. First you'll see the travis.yml is new. We'll look at that in a moment. Then you'll also have package.json. Let's go ahead and look at some of the changes here.

    The first thing you'll notice is we have removed the version from our package.json. This isn't really that big of a deal because when we actually release, then travis will do the releasing and semantic release will actually add the version to our package.json right before it releases.

    We don't have to worry about what version our library is in. We're just using some conventions with our commit messages to specify the types of changes that we're making, and then semantic release is able to determine the version based off of the changes that are in our Git history.

    I'm going to actually restore the version and just set it to 000and say it's semantically released. The reason why I'm doing that is when I run npm install, npm will give me a warning if my package doesn't have a version, so I'm putting that back in there.

    With the scripts, it's adding a script semantic release, and it's calling semantic release pre, and then it is doing the npm.publish for us, and then semantic release post. Semantic release does a lot of magic under the covers to make sure that things are ready for when this npm.publish happens, like setting the version properly. It's also updating our url to be https url, and it's adding the semantic release dependency to our dev dependencies.

    Now let's go ahead and take a look at the travis.yml. It's specifying we don't need sudo, it's specifying our language, setting up the cash so we don't install our known modules over and over again. We don't need a notification, or we can set that up if we want to.

    It's saying before install, go ahead and install the latest version of npm at 2.0Before we run our script we'll npm prune, and then after we run our script, after our script is successful, then we run the semantic release script that semantic release created for us here.

    Now we're going to go ahead and configure travis to make sure that we run the build before we actually release. We don't want to do any sort of releasing before we verify that our tests are working.

    Let's go ahead and add a script here with npm.runtest. Now our test will run, and if they fail, then this after success will never run and we won't release a new version. However if they do succeed, then we will release a new version, and semantic release will find out what version it should be based off of our git commits, and we'll talk about that in the next lesson.

    Just to review, what you need to do is you run npm.install -g globally, semantic-release-cli, and then setup. That'll take you through this prompt here. Depending on what CI you decide to use, it will create a travis.yml if you choose travis.

    Here we have the travis.yml here. We added this script here to make sure that we are running our test so we don't push out a new release if our tests are breaking. Semantic release added this script which it's using in the after success.

    That is how you set up your repository to be released with semantic release.