I’m not only a writer. I’m also an avid DEV Community reader, and I use to find interesting stories about different topics. This time I learnt how to use Husky, among other tools, to improve team collaboration in Git. I’ll spread this habit to my colleagues soon.
I was reading @werliton series about productivity, and I discovered a way of optimizing Git contributions with Husky: his solution is quite different from mine, but I took inspiration to build it. I chose Husky to use Git hooks to only have standard commit messages which can be immediately understand.
Recently, in my company, I was placed in a new team of just three people including myself: I work as a full-stack developer for a corporate, and we will transfer knowledge about legacy products to new colleagues on two different continents. Therefore, maintaining consistent documentation will be crucial.
We use GitHub and have lots of repositories, since we mainly provide professional services: we do product customizations on a daily basis, and as a mid-senior professional I own dozens of repositories that will soon need to be maintained by newcomers.
Of course, I already knew Semantic Versioning and Conventional Commits. Our colleagues from the product development team uses them via lerna, but we don’t make commits to the company monorepo, and we don’t have automations to handle them. We need a strategy.
And, being the most seasoned active developer in the team, I’m responsible of defining it. So, I think that using Husky will make our collaboration easier, since it helps to build consistency in commit messages by forcing Conventional Commits. I’m training a junior colleague who will benefit from it.
Our stack is a mix, but it’s mostly based on Node.js, then Husky can be the best tool here, along with commitlint. The first adds Git hooks to the repository, while the second checks for comments validity on committing. Below, the development dependencies to add in each single project.
npm i -D @commitlint/{cli,config-conventional} husky
npx husky init
There’s no TypeScript support in commitlint to date, so you have to create a JavaScript file instead. Most tutorials provide a CommonJS syntax, but I’m on ESM already and I’ll show you this latter. We have at least two configuration files to edit: one for each new dependency.
EDIT: commilint do support TypeScript, so you can use its extension for configuration files.
mv .husky/pre-commit .husky/commit-msg
echo "npx --no -- commitlint --edit $1" > .husky/commit-msg
echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.ts
Doing so, you can no longer set messages that don’t follow the Conventional Commits standard, because Git will refuse to perform a commit. You could also set further rules to force, for example, the reference to Jira tickets: I think I will provide something to achieve this, but it’s enough to have a basic setup yet.
Semantic Versioning and Conventional Commits are the basis of open source contributions. Even if you don’t contribute to open source projects, they still matter: every developer uses them to share their code. So do I, and I think you should as well. More hints to follow.
Top comments (0)