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

The "Changelogs" 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 add a Husky configuration that ensures that commits are in alignment with a specific convention the developer is trying to set up. How to use Husky to add additional git hooks is also discussed in this segment. Husky is a package that prevents bad commits in a given repository.


Transcript from the "Changelogs" Lesson

>> Where we last left off. We had tests working, linting working. We just now got script D in place, which allowed us to take all of the things that would have been in our script object within each packages, package, JSON We've moved that all out to the root of the workspace and we have a really nice and manageable set of things that apply to our packages.

Instead of things that apply to our workspace each very clearly in its own labelled folder. That way, we can have a builds that's for the whole project and then each package has its own built. So we don't need to change the names of these things. We can just be what people expect them to be.

scripty is a really, really cool little tool there. Next we are going to We're gonna apply some more opinionated stuff to this repo. And the point here is not that any specific opinion is the right one, but having an opinion, gives us benefits. And I'm talking strictly now about commit messages.

So we right now can make commit messages however we like. In fact, if I look at the commit messages here we've got like, first break and linting and learner, right? Just one word each. We're going to establish a convention. Actually we're going to adopt a distinct an existing convention.

And we're going to enforce that convention. And because of that, we're going to get automatically generated change logs, and automatically bumping version numbers. So when we add a feature, we'll see a minor release. When we fix a bug, we'll see a patch release, and so on. So we get a lot of good automation.

Just by aligning with this opinion and the opinion we're going to align with is called conventional change lug. Now the idea here, so this is the home of the project. The idea here is that you have a cli. You have some tools like commit lint, which we're going to use today.

Commit isn't, is it's kind of like a prompt like a multi step wizard that helps you assemble your commit message. Right It asks you questions, you provide your answers, and it gives you a nice commit message. So it's a family of tools that sort of align around a single convention.

And that is that commit messages should have a semver specifier like feature, fix Breaking change. a chore,chore might just be build scripts, right? We're not releasing new packages, we're just fixing the scripts and then a description of what's going on. So with that, let's install the packages that will help us do this and, We're going to be using this little config file.

Actually, we can get this out of the way. Let's just drop this in the root of our project. So I'm going to grab this. Copy and Paste. So I've got this commit lint, config j. s here. And we got to install a few packages and these will all be at the workspace root.

So we're gonna say yarn, add workspace, Dev DEP. Commit Lyndsey Li. Commitment config, conventional commitment config lerna scopes. So this will force us to say For a given commit, which packages will this affect? install, commit, lend itself the root package and then two more Husky and then learn a change log.

And I will show you my package JSON here because it'll be much easier to read. In terms of what I just installed. I take a look at that. So here you go. Anything with this little this to the left, that is what I just installed. And as long as you get the same major version as what you see on my screen, you should be good to go.

We're gonna add a little piece of configuration to our package JSON as well. So this Husky package that we installed. It is a nice little library that helps us wire up Git hooks. And this will make sure that as we're making our commit We validate and we only allow that process to get commit process to complete.

If the commit message aligns with the convention we're trying to maintain a convention isn't worth much, if there's no enforcement mechanism, because of we're to trust that release numbers and change logs. They're based off of The new commits since the last release that had better be good information.

We can't let people slip things in there, slip into breaking change. And we won't detect it if it doesn't align with the convention. Now you have a lot of control,i will leave it as an exercise to to you, the viewer. You have a lot of control over what convention commit lint detects.

I'm aligning with the most common one because it lets us use a bunch of other tools and take advantage of that goodness. But you can, customize things you can customize the way your change log is represented. Just know that if you start to get. You start to deviate from the norm.

it's more likely that some of these tools that we're looking at they may not work as easily as you're about to see them work. So husky because it installs get hooks like it has to set itself up. And frankly, I don't actually remember, How it sets itself up.

But what I do remember is exactly how I can discover this information. I'm going to look into the package JSON. Hey, look at this. So we've got an install hook. We have a post install hook. Right? We have so pre publish. Post publish this has to do with publishing a new version of Husky itself, but this post install hook.

It's gonna run whenever I run yarn install As is this so that tells me what I need to invoke in order to get Husky doing its thing. For example. I just want to create a commit with the message foo. Actually seems to have done something here. In this, honestly this might be because I already had Husky installed here.

So you might not see this. Now what you definitely don't see is evidence that I am being asked to conform to a particular standard like, I just made my commit and it's obviously just a junk Commit message. So undo that one. Being careful with these commands because Git reset is potentially destructive.

So this is just saying it's a soft reset. Just take what I just, Take the commit I just made and like, let's get them back. It's just staged changes. Let's undo the commit but don't throw anything away. So, let's, let's run yarn install. Just to like trigger that hook, being run, let it do any of its setup stuff that it's going to do.

I don't know if I'm going to see any evidence here. That it did its thing.

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