Semantic Release

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Kent C Dodds: We're going to talk about automating releases a little. But before we get too far into that, I wanna talk about why you would ever want to automate releases. So even earlier, right after I ran npm publish, I just realized that I forgot to run the build. Luckily, I had run the build earlier, so it wasn't that big of a deal.

[00:00:22]
But if you had a fresh clone of this, you deleted the dist or something, and you run npm publish, you're gonna be publishing nothing. And then you'll have to do npm deprecate 1.0.1 or whatever, or it would actually be github names@1.0.1. Say, I think the command line flag is -m, like 'I am not smart', or something.

[00:00:50]
It would be so embarrassing. And then you give everybody's npm console if they install your package, deprecation warning, and it's really frustrating. So the fact of the matter is there are a lot of manual steps associated with releasing a package. And that's why we wanna automate things. And so there are actually even more things that we haven't covered that you probably want to do like releases on GitHub and and the change log.

[00:01:18]
So if we go to your package on GitHub, whatever your package is. You won't have this tab here, but I do. But I have a Chrome extension that adds that. To get to this you go to, boy, I don't even remember how to get to that.
>> Kent C Dodds: How do you get to releases?

[00:01:38]
I can't remember. I'm crippled by my tools. Okay, yeah, releases is right there. And you'll see a bunch of little things here. That's because you forked from my repo. But these releases are really just tags, they're git tags. If you actually look at the original project, kentcdodds/starwarsnames, then these tags actually have meaning.

[00:02:07]
They have metadata associated with them. It looks like that metadata doesn't cross over when you fork a repo. But they have a change log associated with them. So every single change has all the list of things that were changed in this release, and that's really handy. Lots of other projects you'll see, like the Angular project, for example.

[00:02:29]
Angular, Angular, they have a change log as one of the files in the repo itself. And it is enormous it is yeah, like it's huge. And it's pretty cool that you have this place that has lots of documentation, but you can do all the same stuff in GitHub releases.

[00:02:52]
And so I kind of prefer to do it that way. But in either case, both Angular and starwarsnames is automating the generation of this change log. And the way that it's being automated is through git commit messages. So for example, if we look at this $animate change right here, and we'll pop open the commit hash.

[00:03:12]
So that's a link. We'll go to that commit, and we'll see basically that same thing. It's just got this dot dot dot stuff. But it references two issues here. And those issues are referenced, or linked, right here in the change log. And so the way that this is generated is here we have bug fixes.

[00:03:35]
We go in here, that says fix. And then $animate is bold here. And that comes from what's called the scope, so the scope of the change. And then the short message here is coming from the subject of the change. And then we have fixes and closes, and those are associated, as well, right here.

[00:03:59]
So all of this is generated based off the commit messages. You can look at all of these, even the ones that have longer messages, it's all coming from here. So the reason that you would do this is because, well, there are a couple of reasons that you do this.

[00:04:20]
One is it's a real pain in the neck to have to update the change log every single time. I've done that manually, it's really annoying. And part of the reason that it's annoying is because I've already kind of written what the changes were. I wrote them in my commit message, so now you're asking me to write them both in my commit message and in the change log.

[00:04:39]
No, let's write good commit messages and generate our change log. So that's one of the cool things that semantic release allows you to do, is it will create that commit messages. Or it will take your commit messages and generate a change log for you. And it puts the change log as releases in your GitHub repo.

[00:05:02]
So if I wanted to, well, dear, things are kinda messed up here because we already have a bunch of tags and stuff. So I'll tell you what we're all gonna do. We're all gonna publish a breaking change to our libraries. But we're not actually gonna break anything. We're just gonna push out 2.0 so that all the tags that you already have in your repos don't cause problems when we go to automate this release.