Committing a new feature 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.
[00:00] Now, let's go ahead and add a new feature, commit that, and see what happens with the semantic release and that new feature. Let's go to our source directory and we're going to add a new feature that will allow us to specify how many random names that we want.
[00:16] Let's go ahead and jump into our test. Inside of our "Random describe," we'll say it should return an array of random items if passed a number. Our API will look something like this. We'll say var random items equals star wars.random-3. We'll expect random items to have length of three. Then, we'll go over the random items for each item. We'll do the same assertion that we have up here except instead of random item, it will simply be item.
[01:02] Now, if we run NPM test, we have a failing test here. Let's go ahead and develop this feature. We'll pull this unique random array out into a variable called "Get random item." Then, instead of assigning random to Get random item, we're going to assign it to a function we'll create called random. This function will take a number. That number will be optional. We'll say if number is undefined, then we'll simply return Get random item just as before.
[01:41] Now, it can't read property length if undefined. We need to add an else case. We'll create a new array, random items. We'll say for var I equals zero, I is less than number, and I++ standard for loop. We'll say, random item.push Get random item. Then, we'll return random items. We save and our tests are passing. We're ready to go with this new feature. I would cancel this and I'll clear.
[02:15] Now, because we're using semantic release, we don't need to worry about updating the version here. In fact, we don't even need to worry about creating a changelog and documenting our changelog. All of the documentation happens inside of your commit messages.
[02:29] We're going to run this commit script. Let's expand this out a little bit. We'll say, "Get status." We have two change files. We'll get add. We have those ready to be committed. Now, we run NPM run commit rather than git commit. This will take us through our prompts. We'll say this is a new feature. The scope is the random function. We'll write a quick description. We'll provide a body.
[03:00] We actually have an issue on github for this feature. It's issue number two, and we can reference that in our commit message. We'll say, "Close this number two." Then, if we had any breaking changes, we would add that as a breaking change and define our breaking change. We don't need to do that.
[03:20] Our commit succeeded. If we look at our gitlog, we'll see we have our feature for random, our subject, and our body and our footer. That's how you add a new feature using the conventional commit style.
[03:37] Now, when we push up to our github repository, our travis build will run and semantic release will know that it needs to release a new minor version because of this new feature. That's what we'll talk about next.