Creating an Open Source JavaScript Library on Github

Exercise: Automating Releases Part 1

Kent C. Dodds

Kent C. Dodds

Professional Trainer
Creating an Open Source JavaScript Library on Github

Check out a free preview of the full Creating an Open Source JavaScript Library on Github course

The "Exercise: Automating Releases Part 1" Lesson is part of the full, Creating an Open Source JavaScript Library on Github course featured in this preview video. Here's what you'd learn in this lesson:

In this exercise, Kent begins the process of automating releases for the library project. He installs and configures the semantic-release-cli module, explaining each step along the way. He then looks at all the changes the semantic-release-cli module made to the project.


Transcript from the "Exercise: Automating Releases Part 1" Lesson

>> [MUSIC]

>> Kent C. Dodds: So let's go and automate this process, because I'm sick and tired of having to push more patch releases. So yeah, let me just double check my notes here, make sure I don't miss anything.
>> Kent C. Dodds: Yeah, we just have, and actually,
>> Kent C. Dodds: Yeah, we just have pretty much two things to do, two things left, and then I'll talk about community stuff.

So the first thing that we're gonna do here, if we look at the exercises here. We're going to install a global module called semantic-release-cli. Semantic release is going to do several things for us. First of all, it's going to hook into our travis. So that after our build is successful, it will run a release script that we'll look at in a little bit.

The other thing it will do is, well as part of this release script, it's gonna set up our package JSON so that it has the correct version for us. And then based off our commit messages and the current version available on GitHub. And then it's going to update the GitHub releases page with a release that represents all the changes that we've made.

So it's gonna do a lot of really cool things for us, and it does all of those things automatically. We just have to promise semantic-release that we're going to do the right thing as far as commit messages go. One other thing that I just realized we need to do before that though is, we need to push all of the tags that we've made with the npm version stuff.

Cuz npm version made some get tags, so to do that, you're gonna say git push --tags. And so that way, when semantic-release comes around and tries to determine, okay, what commits are there since the last release? It can look at the version 2.0.0, or 2.0.2 for me, and determine all the commits since that one to know what to release.

Okay, cool, so let's go ahead and install that. And I forgot to mention, I think that some of you, instead of taking the branch, the FEM08.whatever branch. Some of you I think just forked my repo, and then started working off of master off of that repo. That's fine, just be aware that, the master branch of the Star Wars names repo is quite old.

It's like six or seven months old. And so, things are a little bit different from what we've been working on for this whole thing. So you may have to deal with a couple of weird things, artifacts from that. Like you probably already have semantic-release set up and stuff.

So if you, yeah, if that's what you did, maybe you want to go back and kind of start over or something, or just kind of pick up the pieces or something. Yeah, sorry for that diversion. So we're gonna install this global package, semantic-release-cli. I already have it installed so I'm gonna not install that.

But once you have that installed, this is one of the very few packages that I install globally, I try to avoid doing that. But your gonna do semantic-release-cli setup, it's gonna ask you a couple of questions. The first is whether it's private. The capital letter here is the default.

So I'm gonna leave it with the default of no. The registry is the default registry, I'm good with that. My username is my npm username, here's my npm email. And it wants to access my keychain so it doesn't have to ask me for my password. Which is kinda neat, so I'll allow that.

And yeah, so it didn't need to ask for my password, because it's asked me before. And then GitHub, I'll do the same thing. And then it will ask you what CI you're using. So the reason it's asking you about this is because it's going to generate tokens for you for GitHub and npm.

And it will use those tokens to add to your Travis build automatically so that it can do the releasing and the GitHub changelog generation stuff for you. So we'll just say Travis CI, and that'll take just a second, then it'll ask us one more thing about how many versions of node we want to use.

We'll just say a single version. [SOUND] As soon as it finishes, it's generating the tokens and adding those to Travis. So a single version of Node, and then we can look, it actually has made quite a few changes for us. So if we look at the diff, it removed a couple things and just kind of moved some things around.

I actually don't like what it does. So I'm going to revert all that stuff that it did. But I wanted to show you that it does do some stuff. I like the setup that I had. I'll just explain really quick what's it's doing. So its changing the node version to 4, I like 6.

It's changing before install to install version 2 of npm. Version 3 comes installed with node 6 automatically, so we don't need that at all and I don't like npm 2 anyway, version 3 is much better. It does run npm prune which is actually can be a good thing.

So we can leave that, but yeah, either way. And then, it removed our report-coverage and replaced it with semantic-release. I actually want report-coverage and semantic-release to run, and I'll show you why that semantic-release script is here in a second. And it also has this fancy branches exception and that's basically just to not build for version branches and stuff.

But I don't, we don't need that either. It also, in our package,json, removes the version, totally gone. And so you might be wondering, okay so what, like what is the purpose of it removing the version, isn't it supposed to be publishing our library, right? So what it does is there is this semantic-release script that it's added to our scripts.

First thing that it does is semantic-release pre, followed by npm publish and than it wraps up with semantic-release post. So semantic-release pre is going to go to GitHub, find the most recent version, so for me that's gonna be v2.0.0. And then it's going to go to the current master version or the repo that it's building, and it's gonna find the difference between those two.

All the commits between the most recently released version, and the version that it's looking at right now, the version of code. It's gonna find all those commits, and based off of the commit messages, it's going to determine what the new version should be. And I'll show you what that convention looks like, and how you can control what versions semantic-release should, or how it should treat those changes.

So it's things like if you have fix as your type, then that's gonna be a patch. If you have feat as your type, that's gonna be a minor. And if you include the words breaking change in your commit, then that going to be a major. That's just like the quick, quick run down.

So based off of all that, it's going to add a version to your package.json, whatever the version ought to be. And then it's going to run the npm publish script. And because it has our token, it can do that. And then with the semantic-release post, that's going to make a git tag like we did ourselves a little bit ago, and then push that tag to GitHub.

And then it's going to interact directly with the GitHub API to create a release for that tag, and have the changelog made for us based off our commit messages. So that is all it does, it also updates our URL. I'm not sure why it does that, and it adds itself as a dependency.

So that's everything that just happened, we're going to revert a couple of those things. But does anybody have any questions about that? I'm gonna go ahead and wait for the chat here. So any questions from here?
>> Speaker 2: They were getting an error on creating a Travis hook, but I'm not sure if.

>> Kent C. Dodds: So Brett you did have Travis set up, correct? I'm pretty sure you did.
>> Kent C. Dodds: Without a little bit more information, I don't know if I can give any help. It looks like Ivan is having trouble installing globally. If you can't install semantic-release globally, then here's what you can do.

So you do npm install semantic-release-cli and that would install it locally. Once that's installed locally, you can say node-modules/.bin/semantic-release-cli and then setup. So that should work.
>> Kent C. Dodds: Yeah, and Mike, I am gonna show examples of that commit message format. And I'm also gonna show you a tool that can help you create your commit messages in that format, which is pretty handy.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now