Adicionar Linter de Commits

[juaoantonio]

Acho válido implementar uma padronização dos commits, tendo em vista que este projeto pode contar com participação de terceiros.

[Victoreisdavid]

Boa noite João!

É realmente uma boa ideia padronizar os commits do projeto, para facilitar a entrada de novos colaboradores.
Aproveitando aqui para perguntar, como você sugere que seja padronização?

[juaoantonio]

Existe já uma ferramenta pra isso, o commitzen. Para usá-lo, você tem que configurar outra ferramenta chamada husky, mas já estou implementando e daqui um tempo mando um pull request

[wellwelwel]

Fala @Victoreisdavid 🚀

---

Sobre o padrão de commits, isso pode ser feito de várias maneiras, inclusive com zero código.

A mais fácil, é simplesmente adotar um padrão "a partir de agora" e então, caso alguém queira contribuir, a mensagem do commit em si e até a quantidade de commits são totalmente irrelevantes uma vez que você pode usar a opção Squash and Merge do próprio GitHub nos PRs enviados e substituir pela mensagem que você preferir.

Por exemplo, se um PR criando uma funcionalidade para visualizar os deputados mais visitados tiver 30 commits, um com uma mensagem mais doida que a outra, quando você mesclar usando a opção Squash and Merge, você pode colocar uma mensagem sua como feat: most visited e isso vai resumir todos os 30 commits em um único com a mensagem que você definiu.

Dessa forma, sua implementação de código por conta de mensagens de commit será literalmente zero 😎✨

---

Uma recomendação seria o Conventional Commits.

Com ele, você pode inclusive usar uma ferramenta do Google (release-please) para criar releases e registrar um CHANGELOG.md automaticamente a partir das mensagens dos commits.

---

Alguns exemplos de commits e como o release-please "reagiria" a eles após os PRs serem mesclados na main:

Mensagem (commit)	Ação (release-please)
fix: indica o que foi corrigido	Incrementa a versão patch automaticamente
feat: indica uma funcionalidade nova	Incrementa a versão minor automaticamente
(qualquer prefixo)!: indica qualquer coisa	Incrementa a versão major automaticamente (breaking change)
chore: indica uma tarefa rotineira	Não faz nada
(qualquer outro prefixo): indica qualquer coisa	Não faz nada

---

Alguns prefixos mais comuns:

• fix:
• feat:
• ci:
• docs:
• chore:
• refactor:

E assim vai 🙋🏻‍♂️

[wellwelwel]

Um exemplo bem simples pra configurar os releases e change logs automáticos seria criando um único arquivo no caminho .github/workflows/release-please.yml:

Não precisa instalar nada nem criar conta nenhuma, só criar o arquivo mesmo 🧙🏻

name: 'Release Please'
on:
  push:
    branches:
      - main
permissions:
  contents: write
  pull-requests: write
jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - name: Release Please
        uses: google-github-actions/release-please-action@v3
        id: release
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          release-type: node
          package-name: fiscalizaja
          changelog-path: 'CHANGELOG.md'
      - name: Actions - Checkout
        uses: actions/checkout@v3
        if: ${{ steps.release.outputs.releases_created }}

---

Inclusive você pode chamar outras ações caso o release seja gerado com sucesso ao utilizar a condição if: ${{ steps.release.outputs.releases_created }}.

Um exemplo de como seria pra subir um pacote automaticamente no npm.js (que não é o caso desse projeto atualmente):

      - name: Publishing Package
        if: ${{ steps.release.outputs.releases_created }}
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
        run: npm publish

---

E pronto, acabou. Agora é só você adotar o padrão de commits sem mudar nada no seu código ou instalar qualquer dependência adicional 🚀

---

Caso ache interessante, dá uma olhada na documentação oficial de cada um 🙋🏻‍♂️✨