Fluxo de Desenvolvimento em Aplicações React

No mundo JS, há muitas possibilidades de criar um boilerplate, bem como muitos boilerplates disponíveis (por exemplo: create-react-app). Aqui vou falar sobre algumas ferramentas auxiliares para desenvolvimento e como combinar então para criar um fluxo consistente de desenvolvimento que queremos assegurar:

  • padrão de código e arquivo
  • testes automatizados

Padrão de código e arquivo

Você tem seu .eslintrc configurado e? Vamos fazer algumas perguntas.

Como posso mostrar o padrão de código para outros desenvolvedores?

Então, você e sua equipe estão no mesmo ambiente. Como você pode mostrar warns ou errors para outros desenvolvedores em tempo real (enquanto estiver recarregando)?

Ok, mas como posso evitar que outros desenvolvedores realizem commit em desacordo com o meu .eslintrc?Você precisa adicionar o eslint-loader no seu webpack e impor o uso ‘pre’ do seu js loader.

Bem… Podemos resolver isso também! Você só precisa impor seu .eslintrc usando um hookpara suas ações do git. Uma ótima lib para fazer isso é githusky. Então, dentro do seu package.json:

Muito bem, mas eu tenho alguns padrões que não podem ser processados ​​por lint. Por exemplo: todos os meus arquivos na pasta Modal devem ser: * Modal.jsx. Como posso impor isso?

Provavelmente você está perguntando o que diabos é lint-staged? Você pode estar trabalhando em N arquivos, mas commitar apenas um conjunto desses arquivos (staged-files), de modo que o lint-staged serve para para aplicar o comando eslint somente nesses arquivos.

Esse tipo de padrão precisa ser processado por um testador (consulte o próximo tópico).

E sobre editorconfig e prettier?

Lint não pode formatar o código para nós (isso não é totalmente verdade porque nós temos lint –fix). De qualquer forma, a idéia de usar o editorconfig é fornecer à sua equipe de desenvolvedores um padrão de editor que facilitará o estilo de código. Ao passo que o prettier tem por função formatar o código automaticamente, mas para isso você precisa colocar em um pipeline ou você pode apenas recomendar um plugin para sua equipe e o código será alterado ao vivo.

 

Nota Pessoal: Eu não gosto de mudar o código de outro sem o consentimento ou sem deixá-lo ciente sobre essa mudança, por isso que eu não uso ou encorajo prettier em um hook ou em qualquer pipeline.

Testes Automatizados

Em nosso git husky, temos um pré-push que executará nossos testes e evitará que um desenvolvedor desavisado envie algum arquivo em desacordo com seu padrão. Além disso, podemos impor padrão de arquivo, criando um teste e automatizar esses testes, criando um gancho para o nosso push. Agora nós temos um fluxo assim:

 

 

E um ambiente frontend à prova de fogo.

Plugins Recomendados:

Published by

Marcello Marques

Full Stack Developer

Leave a Reply

Your email address will not be published. Required fields are marked *