O Guia do Mochileiro Dev é um blog para compartilharmos nossos aprendizados e também é um projeto open source, ou seja, voce pode contribuir com alguma feature, correção de bug e etc. Como várias pessoas poderam contribuir com o projeto temos a necessidade de criar um padrão de código para ser seguido.
❗️ Só serão aceitos PR que estiverem seguindo o padrão de código ❗️
Toda feature, correção de bug, adição de qualquer coisa deve ser criada uma branch nova apartir da main, com prefixo de acordo com o que vai ser adicionado. Segue abaixo a lista de prefixo:
Serve para branchs de correção de bugs.
Serve para branchs de criação de novas features, componentes, páginas e etc.
Serve para branchs de correção que não sejam bugs, como por exemplo alterar um texto ou uma cor.
Serve para branchs de melhorias de projeto, como aumentar a performance, layout e etc.
Seguimos o padrão do conventional commits.
test: indica qualquer tipo de criação ou alteração de códigos de teste. Exemplo: Criação de testes unitários.
feat: indica o desenvolvimento de uma nova feature ao projeto. Exemplo: Acréscimo de um serviço, funcionalidade, endpoint, etc.
refactor: usado quando houver uma refatoração de código que não tenha qualquer tipo de impacto na lógica/regras de negócio do sistema. Exemplo: Mudanças de código após um code review
style: empregado quando há mudanças de formatação e estilo do código que não alteram o sistema de nenhuma forma. Exemplo: Mudar o style-guide, mudar de convenção lint, arrumar indentações, remover espaços em brancos, remover comentários, etc.
fix: utilizado quando há correção de erros que estão gerando bugs no sistema. Exemplo: Aplicar tratativa para uma função que não está tendo o comportamento esperado e retornando erro.
chore: indica mudanças no projeto que não afetem o sistema ou arquivos de testes. São mudanças de desenvolvimento. Exemplo: Mudar regras do eslint, adicionar prettier, adicionar mais extensões de arquivos ao .gitignore
docs: usado quando há mudanças na documentação do projeto. Exemplo: adicionar informações na documentação da API, mudar o README, etc.
build: utilizada para indicar mudanças que afetam o processo de build do projeto ou dependências externas. Exemplo: Gulp, adicionar/remover dependências do npm, etc.
perf: indica uma alteração que melhorou a performance do sistema. Exemplo: alterar ForEach por while, melhorar a query ao banco, etc.
ci: utilizada para mudanças nos arquivos de configuração de CI. Exemplo: Circle, Travis, BrowserStack, etc.
revert: indica a reverão de um commit anterior.
Utilizamos como design pattern o SOLID. Referência para o uso com React, TypeScript e SOLID
Todos componentes devem ser criados utilizando o comando yarn generate, este comando já cria automáticamente os arquivos necessários.
Todos os arquivos devem ser testados com no minímo 90% de coverage. Os testes devem ser separados em fluxos de cada função dentro de um describe específico, exemplo abaixo:
Arquivos TSX como componentes, páginas deverão ser escritos com a primeira letra maiúscula no padrão PascalCase. Arquivos de função, hooks, types, index, styles deverão seguir o padrão camelCase, exemplo:
Todos elementos HTML devem ter um componente criado no style.ts e utilizar o import all aos invés de importar um por um, exemplo:
Utilizamos os paths absolutos, então não é necessário ficar fazendo '../../.../', exemplo:
Ao declarar funções sempre utilizar const ao invés de function, exemplo:
Ao utilizar funções assíncronas sempre utilizar o await ao invés do .then, exemplo:
