Closed henriqgoncalvs closed 1 year ago
Fala @hnqg, vou dar minha opinião sincera após usar muito isso no dia-a-dia.
Eu não curto usar o lint-staged mais 😮
Por que? Ele aumenta muito a fricção na hora de dar um novo commit, deixando o processo muito lento às vezes pra uma alteração que não mudou nada de código tem que checar toda parte de linting e tipagem.
Eu to curtindo muito mais deixar essa checagem de linting e tipagem para o ambiente de CI com Github Actions e deixar alguns comandos para a pessoa executar o linting e type checking na máquina dela mas nada atrelado ao commit.
A única coisa que curto usar localmente é o commitlint pra evitar que a mensagem de commit suba de uma maneira ruim.
O que acham?
Fala @hnqg, vou dar minha opinião sincera após usar muito isso no dia-a-dia.
Eu não curto usar o lint-staged mais open_mouth
Por que? Ele aumenta muito a fricção na hora de dar um novo commit, deixando o processo muito lento às vezes pra uma alteração que não mudou nada de código tem que checar toda parte de linting e tipagem.
Eu to curtindo muito mais deixar essa checagem de linting e tipagem para o ambiente de CI com Github Actions e deixar alguns comandos para a pessoa executar o linting e type checking na máquina dela mas nada atrelado ao commit.
A única coisa que curto usar localmente é o commitlint pra evitar que a mensagem de commit suba de uma maneira ruim.
O que acham?
Gosto dessa ideia tbm @diego3g . Faz sentido juntar então a configuração do commitlint e a criação do .yml pro gh actions nessa mesma task?
Se sim eu modifico e já pego ela pra fazer
Acho que podem ser coisas diferentes :)
Fixed on #74
Descrição 📝
Como discutido em https://github.com/diego3g/rsxp-2023/discussions/26, seria importante adicionar uma padronização tanto no formato dos commits.
Objetivo 🎯
commitlint
para padronização dos commitsComportamento esperado 👁️
Ao fazer um commit, a mensagem deve ser analisada pelo commitlint. Se ocorrer um erro no formato, o commit deve ser barrado.