JavaScript and TypeScript Monorepos

Validating Commit Messages

JavaScript and TypeScript Monorepos

Check out a free preview of the full JavaScript and TypeScript Monorepos course

The "Validating Commit Messages" Lesson is part of the full, JavaScript and TypeScript Monorepos course featured in this preview video. Here's what you'd learn in this lesson:

Mike demonstrates how to use the Husky package to check that commits follow a specific convention, and demonstrates how to write valid commit messages.


Transcript from the "Validating Commit Messages" Lesson

>> So there's something we can run. It's in my bash history. So I'm just there we go. So take a look at this. I am echoing out a statement, like some text and I'm piping it to commitment. This is a great way if you're fiddling with things, you're trying to make sure you understand what should be allowed to work and what doesn't work.

This should make it work here. Now, I'm also seeing evidence here that maybe I don't have a global commitment installed. I should be able to do this though. There we go yarn commit lead, right that's going to look in my node modules. It's not going to rely on a global installation.

And now we can see all right. I see a problem with the the sample commit message here. Right, it's saying the scope must be one of the following. So it's a look API. This is my scope. I need it to be a package name. Like you need to tell me which package you affected.

And I have no package called API. If I change that Two types. Maybe it'll be happy and it's happy. That didn't actually make commit. All we did was validate the commit message. I'm going to install a global commitment just in case that is part of a little challenge I'm running into here folta install commitment.

That's gonna be that's like NPM install dash G or yarn global add something like that. And then the first variant that I ran, right? So I, this was what ended up being successful previously. This failed. I bet it works now. And it does. I mean, the command is invoked successfully and as it should, it's telling me that API is not a package in my repo.

One of the things that's tricky, about Husky is sometimes I find that it's tough for it to pick up on changes in particular. Once it's set up some scopes, some hooks, rather. Sometimes it's hard to get them to sort of update and let's see what we have. So there's my Husky sh and Husky local sh and then there is my commit message.

So they're like Huskies. Obviously, it's dropped all of this stuff in here. In an effort to sort of to receive these, like when, what this is where I get expect hooks to live, and the Husky package is now going to sort of like, catch it. And do something about it depending on how we have things configured that's kind of how it works.

The Husky thing isn't the most important aspect of this and I don't want to drill in too deep here, but let me tell you what that would do. It would It would kind of like, bust me if I made a commit message that deviated from our conventions. What's important is that we aligned with our conventions and we're just going to be good about it here so that you can see what happens with the change log and you can see how that's taken into account when versioning things So you want to commit message that looks like this.

So you'd say this is a feature. So I'd say feet and an effects the types package. And then this is where you would write your description to be something like More reasonable default types for generics something like that sounds sounds like a very fancy feature I've added instead, so this is fine, but if I just said Like that, it seems to like that as well.

Maybe I need some additional linting configuration to say only feet is added. only feet is allowed, right this is what this should be what describes you're like whether this is a breaking change, non breaking change. Or patch, or chore or docks, things like that. And these will become subsections of your change log when that the change log generation happens.

So here's how we would do this git commit message. Actually, we can read her message in here. So we'd say, This would really be a chore to be quite honest. But I want to bump our version number deliberately so that I can show you how that works. So let's pretend that this is like a minor release where the change now this is really truly just a chore.

But we'll call it a feature. And we'll say it affects utils. Conventional. Commits and commitment. This is an effort to see if we can get automatic changelog generation and versioning. Cool, all right, so we have our commit.

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