Advocating for Better Code Quality Controls: The Limitations of Husky and Git Hooks

If you’re a software developer like me, you’ve probably encountered Git Hooks and Husky in your coding journey. They sound like a good deal, right? Running predefined checks before each commit to catch issues early. I thought the same until I started grappling with the realities of these tools. Development Workflow with Git Hooks and Husky

The Trouble with Git Hooks and Husky

You know the drill: you’re cranking out some fantastic code in your zone. It’s not quite polished yet, but you want to save your progress and commit your changes - only to be slapped with a cascade of linting errors or failed tests; so much for that smooth coding flow. When you’re knee-deep in development, it’s not uncommon to commit code at various stages - and it’s not always going to be picture-perfect. Git Hooks and Husky, however, aren’t so forgiving, blocking commits for even the slightest transgressions. And here’s the kicker: these rules are more iron-clad than you’d think. Git Hooks are bypassed altogether using the - no-verify option. So, we end up with a system that’s both a pain to deal with and easy to dodge. This inconsistency needs to be doing our codebases more favors.

Branch Protection and PR Level Rules: The Unsung Heroes

So, what’s the alternative? Simple: let’s move the rule enforcement to where it matters most - at the branch protection or PR level. Branch Protection and PR Level Rules With this approach, we can commit code at any stage without being stonewalled by prematurely applied checks. The real scrutiny happens where it counts: when the code is about to enter the main codebase. Another advantage? No more skipping rules. Checks at the PR level are applied uniformly, keeping our codebases consistently clean and our developer workflows unobstructed.

Final Thoughts

Initially, I welcomed Git Hooks and Husky as gatekeepers of code quality. But after seeing them in action, we’re better off without them. By enforcing rules at the PR level, we can make coding less about avoiding pitfalls and more about innovating and solving problems - how it should be. After all, we’re developers, not acrobats jumping through hoops.