Check out a free preview of the full Enterprise UI Development: Testing & Code Quality course

The "Husky & Lint-Staged" Lesson is part of the full, Enterprise UI Development: Testing & Code Quality course featured in this preview video. Here's what you'd learn in this lesson:

Steve introduces Husky, which is a command-line tool for generating pre-commit scripts. These scripts can catch linting or other code issues when code is committed versus waiting for a GitHub action to run.


Transcript from the "Husky & Lint-Staged" Lesson

>> One last thought, and then we pull this train into the station, and we are done with how do you maintain sadness. So the most junior engineer on my team, I don't know what happened, but for some reason, her prettier configuration, her editor was formatting files different than what our build process was doing.

And so all of her PRs failed the, we gotta fix the department of working remotely is you can't be like, hand me your computer, let me figure out what's going on. Cuz like, pair programming on what your editor plugin is formatting your code, with, impossible. But it occurred to me, that's not her problem, that was a me problem, right?

I have a process that clearly if your editor wasn't configured magically everyone on my team else had their editors configured the same way, or for a junior engineer who just doesn't know that you set these things, she couldn't have a PR that could be merged. And then we had this comedy of errors where I tried to be a good mentor, and I was, actually, I'm a bad mentor in this story.

I was like, I will push a commit where I fix the formatting to make prettier satisfied cuz my thing does it right, and I will just run prettier--write and solve everything. And the problem is again, working remotely, I was like, I'll just do this, I'm in the middle of a meeting.

I hope none of my team, cool, they know I don't pay attention to meetings, my actual co-workers, if they make it this far in the course, I'm in trouble. I would push a commit but she didn't know that I pushed the commit, then she would push the commit, but her editor would re-break everything.

But she thought because there was a change that it fixed everything, and then we would go from green to red, to green to red, to green to red. What would be great is if something was willing to tell me in advance if life is okay, right? And this was a tool that I use while back I will tell you like the escape hatch bit me, but we'll talk about this.

So I'll just install it in this repo, we'll find out what happens. There's this tool called Husky, and it's got some friends that we'll talk about in a second as well. In this, you should probably, npx does not install things, npm install husky. Husky takes advantage of a feature in Git, which is there are Git hooks, right, which are functions that are called, and they are written in Bash, and I don't as we saw me trying to kill a port.

There was a time that I knew Bash, it was 15 years ago and you see that I still use the GitHub UI cuz I don't choose to live on the command line when I can avoid it. Have I thought about building an electron app that spins up my stuff?

I have. These are my problems. Husky, and then you have to do Husky install, so npx husky install. One thing you can, if you wanna script that automatically, the prepare script in npm, there are certain ones that run automatically, it used to be post install would automatically run post install, pre install would run pre install.

There's pretest and post test so you could like yeah, there's stuff you can do, we have real build tools now. Prepare will actually run this after you do a npm install so the new people will automatically get these hooks as well. And it's very unassuming, all you say is husky Git hooks installed, and that's pretty great, but one of the things we can do is we could do something like npm husky add, I think I'm doing this in memory unknown command.

We can tell we're at the end of the day because I can't remember npx versus npm. Look, it created pre commit. Cool, let's go ahead and take a look at that. We'll just do pre commit. Presently, it is undefined, right? Things that I could choose to do here and there's a bunch of other hooks, I'll leave it as exercise to the reader here.

I could do an npm run test, right? Now when you go to commit, it will run the tests. Somewhat problematic because like, maybe sometimes I wanna commit cuz, you might all be better than me. And this is why I suppose like where I'm a charlatan, I have stashed things in Git before, I've never unstaffed anything, in a world where the default action is squash and commit.

My good hygiene is abysmal. And so you, running a test is somewhat problematic and like sometimes I just need to commit some things and push it up cuz I'm worried that my computer will be stolen, and I just want them in the cloud, right? I don't necessarily, I know the tests are failing leave me alone, so you could do something like that thing that I it's in the notes but I didn't actually talk about you could do an npx vitest changed.

Which will either be the currently unstaged stuff or you got to do a comparison to another commit. We're only running the test files for stuff that has changed since the last commit, right. So that gives you a much smaller set of tests rather than writing the whole suite.

That will work, you could, to complete our story here, you do npm, and maybe this is npm run format, but just to be super clear, npx prettier --write or whatever, right? And so now, as you go to commit, prettier runs before the commit happens and then adds those changes as well and then the commit takes place, right?

So now I don't have to worry about Grace's editor being set up the way my editor is set up because the actual code base will do it itself and stay self-hygienic in that sense. The other two things that I will just kind of bring to your attention is there's also a tool called npx lint staged.

This does the very simple thing as it takes the files that are about to go into commit, and then passes them to other commands. So you might write a file and it might be called like a linter, I think it's .lintstagedrc, and it's a JSON file.

I was just was just a JSON I will just kind of type one out. And what you can do with lint staged, you have some file which I could explain it to you, but it'll become incredibly clear what it does momentarily. TS or js files do It's a JSON, so I gotta do a double quotes, Right, and it will only pass the files that changed in there, right?

I can do npm run format, I could do Those get passed in as arguments, if it is like a markdown like that'll only be for this case ts and js files or TSX yeah, whatever. Markdown files, I can do like I have a script that renders those to HTML, and like so we can like push them up to the docs, whatever.

It will basically take whatever the stage files you're about to commit are, and it will run them through whatever scripts that you want, and it's a way to combine with husky. Now you're not running the entire code base through these commands, you're only running the files that changed, right?

One of the things I did that you shouldn't do anymore, was back when I had Jenkins and it was in 2017, is we had this abysmal code base, this is the one I think I referred to earlier. It was a Rails and CoffeeScript and jQuery app, that then they ripped out the some or most of the CoffeeScript and jQuery, and placed it with React, but it was their first React app, and anytime they didn't understand anything, they pulled out jQuery and just went for it.

And then they removed the Rails app from underneath. Needless to say, there was no linting or tests. And so the rule that I had was we ran, if you touched a file, you had to fix it, even if you were just doing a minor change, and I bring this up for an important reason.

And what I found out later was I was sprint planning and my manager, everyone was complaining we didn't get anything done because every file they touched, they had to do a bunch of lint fixes for, but everyone was touching the same files. And he was like, do you want to have a meeting about lint rules?

I'm like, never, right? And my rule for lint rules is pick either the recommended or the Airbnb or whatever, just pick one and go for it. I don't wanna talk about this unless it's my opinions on how prettier should be set up. If you ever need to get out of any of these, you do git commit whatever --no verify.

And I found out that the intern knew about that, and the intern was doing it, and then everyone learned from the intern that you could skip all the checks. And then everyone started doing it, so I was like who has done --no-verify this week and everyone raised their hands, I'm like, so the person you hate is at this table, [LAUGH] it's all of you, you're all guilty.

But you can run the lint staged stuff and there's some other tools I'll just bring to your attention, we'll put links in the recording version. There's a tool called Danger which can kind of hook up and stuff, which we'll enforced, did you put a long enough body on your git commit?

There's ways to take some of the process, I don't actually use that many of them. The one of formatting stuff, totally. The one, we have thought because we have an open source code base and we seek to auto generate release notes. We have discussed if we wanna be the people who have to make it, they do chore colon on a git commit versus fix so that we can better process release notes because presently I write them [LAUGH].

For a practical reason, but it like one I will warn you with all these tools and why I will not separate on them too much is, can they automatically prepare your file so you don't break the build? Absolutely. It is too easy to be, I'm gonna have a lot of rules instead of error code based better, you will turn them off and everyone will hate you, probably not other orders, everyone will hate you and then you will turn them off.

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