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

The "commitLint Q&A" 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 answers questions about the commitlint conventions, about the various layers of configurations within commitlint, and demonstrates a situation when a commitlint flag commits that do not fall within the configuration standards.


Transcript from the "commitLint Q&A" Lesson

>> Any questions before I move on other than why are we not seeing the change once the way Mike describe it? I am comfortable leaving that as an excercise to you because I probably just have like a parenthesis in the wrong place, that's not the tricky part yet.

The tricky part is getting this set up and understanding that you have to learn of this I have a question.
>> Yes, please. Is there a config that specifies the convention that we have to follow for cobis Lee? You know what, I think you might have asked the question and it's gonna make this work.

Hold on. Laundry, I think you might have just saved this here. So the config is this can commit lint, that config j s. And I notice here I don't have this conventional commits thing in the config let's see what happens now. [BLANK AUDIO]. There we go. That was it.

There's the config. Right. So the learner scopes thing it's strictly a helping commitment understand what learners scopes are, but this is this main Like configuration for commitlint. This is what's doing most of the lifting. And of course, now Husky is doing its job. I think Husky was always doing its job except now we have, now commitlint is doing something much more meaningful and it's actually stopping us when it should be stopping us.

Let's see if I can make another commit here and we'll see what happens. So we'll say let say that this is fix(utils). Again this is distribute chore but I'm calling it fix. Correction to commitlint config
>> Now it accepts it And I'm going to actually sit on this for a second because we're going to talk about how how we publish packages next.

>> So Can I change the templating configuration? Mean if I have a change in the method of committing this difference?
>> Yep. It is possible that commitment can align with your existing convention.
>> And let me see cheat config. So these are all different patterns. This is almost like a base lint configuration.

You know if you ever seen like the standard, standard JavaScript lint configuration is like I think Brian Holt used to use this a lot in his workshops where
>> They're no semi colons, all sorts of crazy wacky decisions like that. So this is another place where we can choose our pattern but and my advice here is, I'm not saying that exactly the default conventional commits are the important thing.

It's more If you establish a pattern and having an enforcement mechanism in there, your commit history becomes a very valuable source of truth. So adopting a convention is better than no convention, because this is a great source of truth. And it means that some of this stuff can just be automated.

Your change logs can come for free Your picking of versions can. If you have 50 packages in this it's just such a pain to figure out what a version of something could be. Here's why, my new release in a low level package that gets bumped, but then it gets upgraded in six other packages.

And then, those cause upgrades another packages. It sort of all flows through. Figuring these numbers out is really complicated and error prone, if done manually, so you want to have some mechanism where you're not having to figure that out yourself. And the two popular ways of doing this are to use the commit messages.

Or to use labels on pull requests, this is where, for popular open source projects where you don't necessarily you don't have a team where you can train them up and say please go and do this. This lets maintainers decide, this is a feature, this is effects, this is chore And they can kind of like, take on the burden of making sure that all that works properly.

But commitments commitment is pretty flexible, conventional commits is a specific thing. So that's one. That's why it like commitment is flexible, but this specific thing is for conventional And then this one's for Angular. And some of these layer up like we're using learning scopes as well. Right learning scopes is what lets us do.

It lets us do something like this. Right? The parentheses.

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