Categorias
Dicas Nodejs

Adicionando Husky ao seu projeto Nodejs

Não, não é sobre a raça de cães. É uma ferramenta para escrever git hooks de modo mais simples. E aqui vamos direto ao ponto, sem explicar muita coisa. Talvez depois eu faça outro artigo com mais explicações.

A versão 8.0.0 mudou a forma como o husky funciona e como pode ser configurado. É bem simples!

Para instalar ele em seu projeto basta digitar:

npm install husky --save-dev

Isso vai instalar o husky (em julho de 2022 foi a versão 8.0.0) e salvar ele na lista devDependencies do package.json.

Depois de instalar você precisa habilitar o husky. O comando abaixo vai criar o diretório .husky e modificar o caminho do git hooks (configução do git core.hooksPath) para o diretório recém criado:

npx husky install

Esse será o diretório em que os hooks serão salvos a partir de agora.

Agora vamos criar um hook de pre-commit:

npx husky add .husky/pre-commit "npm test"

Ali onde está “npm test” você pode adicionar mais comandos como “npm test && npm run eslint” caso você queira que ele execute os testes e o linter de código. O comando acima irá criar o arquivo pre-commit dentro do diretório .husk.

Não esqueça de adicionar esse arquivo no git:

git add .husky/pre-commit

Pronto, somente com esses passos você já terá o husky configurado e rodando. Para testar, você pode criar um teste unitário que irá falhar e depois tentar fazer um commit pra ver o que acontece!

Para que todos da equipe já tenham o husky configurado ao baixar o projeto e executar o npm install é só criar a linha abaixo na seção “scripts” do seu package.json:

"prepare": "husky install && npx husky add .husky/pre-commit \"npm test && npm run eslint\""

Isso irá fazer toda a configuração do husky quando um desenvolvedor clonar o projeto e executar npm install. Vai criar o diretório .husky, depois vai adicionar o hook de pre-commit com os comandos “npm test” e “npm run eslint“.


Neste pequeno artigo foquei somente em instalar o husky e deixar ele utilizável. Não contemplei aqui testes unitários e nem configurações do eslint.

Uma observação é que para um problema de lint barre o commit o problema deve retornar 2 e não 0 ou 1 (zero é desligada a validação e 1 é somente um warning. O 2 irá retornar um error caso o lint pegue algum problema).

Outra consideração é que o diretório .husky deve estar no mesmo nível do .git. Isso pode ser modificado, mas para uma primeira vez seguir o padrão da biblioteca vai ajudar no entendimento. Quando estiver mais familiarizado você vai olhando na documentação e testando as possibilidades que existem.

Categorias
Dicas

Manias!

Olá pessoas!

Ao longo dos anos de trabalho eu fui desenvolvendo algumas manias no meu dia-a-dia de trabalho. Eu encaro-as como boas práticas que gosto de seguir.

Abaixo a lista de algumas dessas manias. A ordem não quer dizer nada a respeito da importância de cada uma.

  • Assim que é feito o deploy de algum bug-fix ou feature em produção eu apago a branch que aquela solução foi desenvolvida. Isso evita branchs desnecessárias no servidor e que, provavelmente, não serão mais utilizadas. Se, por acaso, acontecer um bug ou faltar algo para desenvolver cria uma nova branch pois, bem provavelmente, foi criado outro card para isso.

  • Gosto de nomear minhas branchs com os códigos do card combinando uma breve descrição. Exemplo: BUG-404-corrige-pagina-n-encontrada.

  • Gosto de salvar todos os scripts que uso para fazer determinada tarefa (pode ser atendimento a algum card ou somente querys do dia a dia. E sigo um método de organização que é: tenho um diretório de nome scripts. Dentro desse um subdiretório para cada card e dentro do diretório do card a(s) query(s) com seu nome dizendo examente o que ela faz. Exemplo:

  • Essa é uma das manias que mais luto para que ela seja seguida por todos nas squads: NUNCA marrete o banco de dados, ou seja, nunca execute um insert/update/delete via script sql. Quando preciso fazer isso e não tenho um método que faça exatamente isso eu crio uma rota (caso seja API) que irá receber a requisição e utilizar o próprio código da API para corrigir. Exemplo: tenho que atualizar o id do fabricante do fone de ouvido que tenho cadastrado na tabela fones. O invés de fazer um update via sql direto no banco de dados, eu chamo a rota de update passando as informações necessárias. Caso a rota não exista eu crio uma seguindo um nome padrão: atualiza-fone-emergencia. Essa rota irá utilizar o código já existente na API para atualizar. Após executar o que preciso eu deleto a rota. Fazendo assim eu consigo fazer as alterações necessárias e seguindo as regras de negócio que já estão todas na API e que, por sua vez, irão gerar logs na aplicação. Sim, sei que irão acontecer casos que realmente seja necessário marretar o banco de dados. Nesses casos não tem muito o que fazer mas, se isso foi necessário, então temos uma falha em algum momento no projeto (arquitetura, levantamento de requisitos, codificação, teste, etc).

  • Documento de deploy. Gosto dele pois consigo criar um passo-a-passo do deploy. Quais PRs devem serem mergeados primeiro, se algum SQL deve ser executado no banco de dados e em qual momento (ordem) e até uma validação (o famoso NUNCA faça teste em produção) após o deploy. A idéia é que mesmo que a pessoa responsável pela alteração não esteja presente, qualquer outra pessoa da squad consiga fazer.

  • Não podia faltar o famoso POST MORTEM. Aqui o objetivo não é identificar pessoas culpadas e sim processos e/ou métodos culpados. O porque aconteceu! Como uma investigação de acidente aéreo onde vai listando os eventos, em cadeia ou não, que levaram a falha (catastrófica ou não). Esse documento deve ficar público para as pessoas envolvidas para que este problema não volte a acontecer novamente, pelo menos não pelos mesmos motivos :).

Tem mais coisas/manias. De acordo que for lembrando vou criando novos posts sobre elas.