Em complemento ao artigo anterior escrevendo commits do jeito certo, nós já vimos um pouco de como utilizar padrões de commit, mas por conta conventional commit pattern ter uma serie de diretivas a serem seguidas isso faz com que haja uma curva de aprendizado para aqueles que não conhecem o padrões ou que nunca aplicou num projeto.
Mas para isso podemos utilizar algumas ferramentas para nos auxiliar tanto na escrita dos commits quanto validação dos commits escritos nos projetos, e um detalhe importante essa configuração vale apenas para projeto em nodeJS, no futuro vou tentar replicar o mesmo artigo para uma forma mais genérica.
Leque de ferramentas
Commitlint
O commitlint é uma ferramenta de linha de comando que faz a validação das mensagem de commit de acordo com padrões estabelecidos na configuração, a partir disso quando passamos um commit por ela, ela faz a checagem dos pontos commit de acordo conforme o exemplo abaixo.
A ideia é utilizarmos ela para dar um "tapa na mão" de quem não seguir o padrão estabelecido no time para as mensagens de commit.
Commitzen cli
Vamos pensar na seguinte situação, temos algum novo no time ou até mesmo todos no projeto não estão familiarizados com a escrita de commits utilizando o conventional commit pattern e sendo menos produtivos porque precisam ficar sempre consultando a documentação ou vendo commits anteriores/de outros colegas para garantir que estão seguindo o padrão correto, isso é um cenário que pode ocorrer e que tem um impacto negativo no uso do conventional commit, podendo desencorajar os membros do projeto ou até mesmo fazer como que tomemos a decisão de utilizar o mesmo, mas para isso nós temos uma ferramenta de linha de comando para no ajudar a contornar isso, o commitzen cli ele basicamente faz uma seria de perguntas que vamos respondendo para compor o nosso commit conforme podemos ver a seguir.
Viu como é simples de seguir os padrões quando temos uma ajudinha, agora não tem mais desculpa pra não começar a adotar o conventional commits nos seus projetos.
Husky
Agora vamos ao husky e antes que você pergunte, não não é aquele cachorro que a gente vê nos filmes puxando trenó, na verdade ele é um pacote que nos auxilia na criação de git hooks, que nada mais são que gatilhos em que podemos executar algum script, por exemplo podemos rodar um script antes de cada commit, antes do push, na hora de preparar a mensagem de commit e etc.
E nesse caso ele vai nos ajudar da seguinte forma, queremos que antes de efetuarmos um commit ele utilize o commitlint para validar se a nossa mensagem de commit está de acordo com os nossos padrões e se não estiver vai ter um cachorro bem bravo pra morder a sua mão.
Brincadeira, na verdade o seu commit não vai ser realizado, suas alterações vão ser mantidas mas até que você crie um commit que atenda os critérios você não vai conseguir commitar.
Configuração
Bom agora chega de teoria e vamos para a prática
- criando um novo projeto
antes de mais nada precisamos criar um novo projeto e para isso criamos uma pasta e nela executamos:
para criar um projeto com o npm
# se você quiser responder os detalhes do projeto
npm init
# ou se preferir usar as opções default do projeto
npm init -y
para criar um projeto com o yarn
# se você quiser responder os detalhes do projeto
yarn init
# ou se preferir usar as opções default do projeto
yarn init -y
- configurando o
commitlint
para configurarmos o commitlint instalamos ele como dependência de desenvolvimento
npm install -D commitlint
# ou com yarn
yarn add -D commitlint
e para não precisarmos criar todas as regras do zero e extendermos das regras que temos no conventional commit instalamos o seguinte pacote em modo de desenvolvimento também
npm install -D @commitlint/config-conventional
# ou com yarn
yarn add -D @commitlint/config-conventional
e ai criamos um arquivo na raiz do projeto chamado commitlint.config.js com o seguinte conteúdo
module.exports = { extends: ['@commitlint/config-conventional'] };
isso vai fazer com que ao rodarmos o commitlint no projeto ele utilize as regras setadas nesse pacote, mas se for necessário podemos adicionar opções personalizadas da seguinte forma
module.exports = {
extends: ['@commitlint/config-conventional'], rules: {
'type-enum': [
2,
'always',
[
'build',
'chore',
'ci',
'docs',
'feat',
'fix',
'perf',
'refactor',
'revert',
'style',
'test',
'foo'
],
],
}
};
nesse exemplo adicionaríamos o tipo de commit foo como um tipo válido e poderíamos utilizar ele no nosso projeto, você consegue achar mais opções de configuração aqui.
- configurando o
commitzen cli
Ok agora vamos configurar o commitzen cli para isso vamos usar um próprio auxiliar dele com o comando abaixo
commitizen init cz-conventional-changelog --save-dev --save-exact
# ou usando o yarn
commitizen init cz-conventional-changelog --save-dev --yarn --save-exact
o comando acima vai instalar os pacotes necessários e criar uma sessão de configuração no package.json conforme descrito a seguir
"config": {
"commitizen": {
"path": "./node_modules/cz-conventional-changelog"
}
}
nela também pode adicionar configurações extras conforme o exemplo anterior, vamos adicionar a opção do tipo foo como um dos tipos disponiveis no commitzen cli
"config": {
"commitizen": {
"path": "./node_modules/cz-conventional-changelog",
"types": {
"feat": {
"description": "A new feature",
"title": "Features"
},
"fix": {
"description": "A bug fix",
"title": "Bug Fixes"
},
"docs": {
"description": "Documentation only changes",
"title": "Documentation"
},
"style": {
"description": "Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)",
"title": "Styles"
},
"refactor": {
"description": "A code change that neither fixes a bug nor adds a feature",
"title": "Code Refactoring"
},
"perf": {
"description": "A code change that improves performance",
"title": "Performance Improvements"
},
"test": {
"description": "Adding missing tests or correcting existing tests",
"title": "Tests"
},
"build": {
"description": "Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)",
"title": "Builds"
},
"ci": {
"description": "Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)",
"title": "Continuous Integrations"
},
"chore": {
"description": "Other changes that don't modify src or test files",
"title": "Chores"
},
"revert": {
"description": "Reverts a previous commit",
"title": "Reverts"
},
"foo": {
"description": "New type to show custom config",
"title": "Foo"
}
}
}
}
e pronto o commitzen cli já está configurado, podemos adicionar um script de commit, para facilitar o uso dele no projeto
"scripts": {
"commit": "npx git-cz"
}
- configurando o
husky
Agora vamos configurar o nosso amado husky que vai ser o nosso "tapa na mão" caso alguém não siga os padrões de commit definidos no projeto.
então agora que você foi avisado vamos lá, antes de mais nada precisamos iniciar um reposítório git, porque como o husky cria os git hooks para o git, se o projeto ainda não tiver um reposítório iniciado vamos instalar o husky mas ele não vai funcionar.
inicializamos nosso repositório local
git init
e depois instalamos o husky como dependência de desenvolvimento
npm install -D husky
# ou com yarn
yarn add -D husky
uma vez instalado temos que configura-lo, então vamos criar uma sessão no nosso package.json com os hooks que temos que usar
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}
- testando se fizemos tudo certo
se todas as nossas configurações estiverem corretas temos que ter os seguinte resultado.
commit inválido
commit válido
Conclusão
Pronto o artigo foi longo, mas pelo menos temos como recompensa um projeto configurado, seguindo as boas práticas do conventional commit pattern e com uma validação automática a cada commit, o código final desse tutorial você pode encontrar aqui.
Top comments (0)