# Criando um PR
Guia de como implementar sua contribuição.
# Padrões utilizados
No design system utilizamos o padrão de componentização Atomic Design (opens new window). Utilizamos esse padrão por entender que fica mais fácil fazer a composição de componentes e evoluir a biblioteca de uma maneira que escale.
Então, nossos componentes são divididos em:
- atoms
- molecules
- organisms
- templates
# Estrutura do projeto
O projeto está separado múltiplos pacotes:
# Documentação (packages/docs)
No que se refere ao projeto da documentação, os arquivos estão dentro da pasta packages/docs, e se usa o vuepress para gerar a documentação. Além desses arquivos, na pasta de cada componente existe um Readme.md que é utilizado para adicionar o exemplo do componente dentro da documentação.
# Biblioteca de componentes (packages/components)
A biblioteca é o que vai ser instalado quando alguém for utilizar os componentes. Os arquivos da biblioteca são todos os que se encontram em src/ com exceção dos Readme.md dentro da pasta de cada componente.
# Biblioteca de Gráficos (packages/charts)
A biblioteca de gráficos segue o mesmo padrão dos componentes. Exceto que não faz uso do atomic design por ter os componentes com um único objetivo e não haver composição de gráficos.
# Linter
Os padrões de código do projeto estão definidos com Eslint (opens new window). Então, antes de abrir um PR, é importante verificar se o código está seguindo os padrões definidos pelo linter.
Faça isso utilizando o seguinte comando:
yarn lint
# Testes
O projeto utiliza testes automatizados, sendo assim, se você adicionou alguma lógica dentro do componente, é importante que haja testes cobrindo essa alteração. Além disso, é necessário que o teste não quebre outros componentes.
Como biblioteca de testes, está sendo utilizado o Jest (opens new window) e para testar os componentes contamos com as utilidades do Vue Tests Utils (opens new window).
Os testes são especiamente importantes, pois o projeto é utilizado em diferentes sistemas e não queremos que alguma alteração quebre funcionalidades de projetos alheios.
Para executar os testes, utiliza-se o seguinte comando:
yarn test:unit
Ao final do processo os testes devem estar passando, como na imagem a seguir:
# Changelog
Se sua alteração adicionou algo novo, ou corrigiu alguma coisa, deve ser gerado um arquivo de changelog para quando for gerada uma nova versão que sejam adicionadas as alterações feitas no changelog da documentação.
Esse processo é feito através do script:
yarn changeset
Este comando vai te fazer algumas perguntas e ao final irá gerar um arquivo com nome randômico na pasta .changesets/.
Seu Pull Request não será aceito se não houver um changeset indicando a mudança feita
# Pull Requests
Se você fez as aterações seguindo os padrões descritos acima. É hora de criar um PR no repositório https://bitbucket.org/zooxcloud/zoox-design-system.
Junto ao PR descreva a alteração que foi feita ou adicione um link para a issue do JIRA.
Após criar o PR envie uma mensagem no canal do Design System para alguém da equipe de UX fazer o review da alteração e aprovar o PR.
# Gerando versão
A versão dos pacotes será gerada a partir do pipeline, se baseando nos changesets gerados. Por esse motivo cobramos que sempre que haja alguma alteração que seja incluido um changeset com a mesma.