A qualidade em primeiro lugar! 5 passos fáceis para aplicar lint ao seu código com fluxos de trabalho do GitHub no projeto JavaScript

O que é que devemos fazer, quando o projeto é pequeno ou o cliente ainda não sabe se vale a pena investir mais? Obviamente, no Fase MVP do projeto, código Os testes de estilo ou unitários não são a principal prioridade. Os investidores geralmente querem ter um bom produto e se funciona, não precisa de ser testado, certo?

De facto, tenho alguma experiência em criar aplicações de raizmesmo sem utilizar as melhores práticas. Algumas circunstâncias comerciais obrigaram-me a procurar o compromisso entre os planos orçamentais de um investidor e a lista de "coisas boas a ter" do programador. Felizmente, se utilizar o GitHub, a maioria dos problemas comuns relacionados com a qualidade do código podem ser resolvidos em poucos minutos.

Neste artigo, vou mostrar como usar os fluxos de trabalho do GitHub no ambiente Node.js para padronizar sua base de código.

Alguns pressupostos antes de começarmos:

• Está familiarizado com o NPM e a consola Linux.
• Tem alguma experiência com pré-processadores de estilo, carregadores de módulos, agrupadores, etc.
• Sabe para que servem os linters e quer mesmo utilizá-los nos seus projectos.

1. Estrutura típica do projeto JavaScript

Se alguma vez utilizou algumas estruturas JS como Vue ou React, pode facilmente detetar algumas coisas comuns entre eles, por exemplo:

• /src com toda a sua lógica e componentes JS,
• /teste para os testes unitários e e2e,
• /activos para estilos, imagens, etc.

Mesmo que estejamos a falar de JavaScript projeto, trabalhamos em Nó por isso, obviamente, também deve haver algumas coisas do Node, como package.json, package-lock.json e /node_modules no nosso diretório raiz.

Todas estas coisas estão no seu lugar - é a isso que chamamos o convenção. As frameworks são inventadas para fornecer algumas convenções razoáveis, por isso, normalmente, nem precisamos de nos preocupar com o padrão de design inicial. Como neste exemplo, eu quero explicar algumas abordagens, não vou aplicar nenhuma solução pronta para uso como o Vue CLI.

Está na altura de perceber o que está por detrás de todos estes guiões mágicos de cotão!

2. Extensão do projeto Node típico

Para fornecer soluções de alta qualidade, os linters são a primeira coisa com que devemos começar ao configurar um novo projeto. Vamos focar-nos em dois linters - Stylelint para estilos (*.scss) e ESLint para ficheiros fonte (*.js). Ambos os linters estão disponíveis no NPM e são bastante fáceis de configurar. Para usar os linters é necessário passar pelo processo de instalação, adicionar arquivos de configuração e definir scripts de projeto. Vamos fazer isso passo a passo.

3. Adicionar o Stylelint

A instalação do Stylelint no ambiente Node é muito simples. De acordo com o documentos oficiais, só precisa de correr:

npm install --save-dev stylelint stylelint-config-standard

e esperar até estar pronto.

stylelint-config-padrão fornece um conjunto predefinido de regras de linting e pode ser substituído por qualquer pacote que se adapte melhor às suas necessidades (por exemplo Estilo Airbnb). Em seguida, crie um novo ficheiro oculto .stylelintrc.json, que é o ficheiro de configuração do Stylelint, responsável por carregar as nossas regras pré-definidas:

{
    "extends": "stylelint-config-standard"
}

Neste momento, a única coisa que falta é algum script NPM (ou scripts) declarado no ficheiro package.json para começar a fazer o linting do nosso SCSS ficheiros. Eis a minha proposta:

"scripts": {
    "lint:scss": "stylelint '**/*.scss' --sintaxe scss -f verbose --color",
    "lint:scss:fix": "stylelint '**/*.scss' --sintaxe scss --fix -f verbose -color"
}

Como podem ver, declarei o script que contém -Correção esta opção deve ser utilizada antes de efetuar o push das alterações para o repositório.

Não se esqueça - é uma má prática utilizar -Correção no seu fluxo de CI, porque então o código que passa para a produção não é estilizado corretamente no repositório. É por isso que precisamos de ambos os guiões.

Vamos testar o nosso linter criando um ficheiro /assets/scss/styles.scss com algum conteúdo, como:

corpo {
                    cor de fundo: #fff;
}

npm run lint:scss

Deverá ver na sua consola algo como isto:

> stylelint '**/*.scss' --sintaxe scss -f verbose --color

assets/scss/styles.scss

2:21 ✖ Recuo esperado de 2 espaços recuo

1 fonte verificada

~/Codest/Projects/github-workflow-demo/assets/scss/styles.scss

1 problema encontrado

nível de gravidade "erro": 1

indentação: 1

npm ERR! código ELIFECYCLE

npm ERR! errno 2

npm ERR! [email protected] lint:scss: `stylelint '**/*.scss' --sintaxe scss -f verbose --color`

npm ERR! Estado de saída 2

Isto significa, de facto, que o nosso linter funciona!

O resultado mostra exatamente qual a linha que causa um erro e descreve o problema a resolver. Alguns problemas não podem ser corrigidos automaticamente, pois precisam da decisão de um desenvolvedor, mas na maioria dos casos, basta executar o mesmo comando com -Correção por isso vamos executá-la.

npm run lint:scss:fix

Agora deve ver uma saída verde sem erros encontrados:

stylelint '**/*.scss' --sintaxe scss --fix -f verbose --color


1 fonte verificada

/Users/wojciechbak/Codest/Projects/github-workflow-demo/assets/scss/styles.scss

0 problemas encontrados

4. Adição do ESLint

Este passo é quase o mesmo que o anterior. Vamos instalar o ESLint, definir um conjunto de regras padrão e declarar dois scripts NPM chamáveis - um para CI, outro para pre-push. Vamos lá!

Se usa o NPM no seu trabalho diário, talvez queira instalar o ESLint globalmente. Se não o fizer, por favor verifique as instruções de instalação em documentos oficiais.

npm install -g eslint

Quando o comando eslint estiver disponível na sua máquina, basta executá-lo no seu projeto:

eslint --init

Seguindo as instruções apresentadas no seu terminal, basta tomar algumas decisões de projeto como

• Javascript ou TypeScript
• Estilo Airbnb ou estilo Google
• tipo de configuração (ficheiro JSON, ficheiro JS ou inline em package.json)
• Módulos ES (importação/exportação) ou exigir sintaxe

Neste lugar, vale a pena escrever uma palavra sobre o formatador de código chamado Prettier. É totalmente padronizado e compatível com a maioria dos editores de código (por exemplo, VS Code). O Prettier fornece muitos conjuntos de regras de estilo de código predefinidas, trabalha em conjunto com linters e pode ser um grande apoio na procura da melhor qualidade do código. Para saber o que é exatamente o Prettier, visite este comparação dos documentos oficiais.

Se for feito, o ficheiro de configuração do ESlint (e.g. .eslintrc.jsondependendo do que tiver escolhido anteriormente) deve aparecer no seu diretório raiz, algures ao lado de .stylelintrc.json criado anteriormente.

Agora temos que definir os scripts em package.json o mesmo que para os ficheiros SCSS:

"scripts": {
    "lint:js": "eslint '**/*.js' --ignore-pattern node_modules/",
    "lint:js:fix": "eslint '**/*.js' --ignore-pattern node_modules/ --fix"
}

Parabéns! O ESLint está pronto a ser utilizado agora mesmo. Vamos verificar se funciona corretamente. Criar /src/index.js ficheiro com algum conteúdo:

consola.log("algo");

Executar o linter:

npm run lint:js


O resultado deve ter o seguinte aspeto:

> eslint '**/*.js' --ignore-pattern node_modules/

~/Codest/Projectos/github-workflow-demo/src/index.js

1:1 aviso Declaração de consola inesperada no-console

1 problema (0 erros, 1 aviso)

Este aviso não desaparece depois de utilizar -Correção opção, porque não afectam o código potencialmente significativo. Eles servem apenas para estilizar o códigoincluindo espaços em branco, novas linhas, ponto e vírgula, aspas, etc.

5. Definir fluxos de trabalho do GitHub

Fluxos de trabalho do GitHub são uma coisa bem documentada. Sinta-se à vontade para se aprofundar no assunto, mas, por enquanto, vou implementar um fluxo de trabalho simples para fazer o lint do nosso código após o push para o repositório remoto (obviamente, hospedado no GitHub).

Criar /.github/workflows e o novo diretório code-quality-workflow.yml uma vez que os fluxos de trabalho do GitHub têm de ser definidos com ficheiros YAML.

Para executar um fluxo de trabalho adequado, temos de responder a algumas perguntas:

• Quando é que queremos executar o nosso fluxo de trabalho (no envio, no pedido pull, na fusão, etc.)?
• Pretendemos excluir algumas situações (como o envio para o ramo principal)?
• Que ambiente precisamos de configurar para executar corretamente os nossos comandos (neste exemplo - Node)?
• Precisamos de instalar dependências? Em caso afirmativo, como devemos armazená-las em cache?
• Que passos temos de dar para concluir o controlo?

Após algumas considerações e algumas horas de trabalho com o exemplo da documentação .yml pode ter o seguinte aspeto:

Nome: Qualidade do código

on: "push" (empurrar)

trabalhos:
  code-quality:
    nome: Lint código fonte
    executa em: ubuntu-latest
    passos:
    - usa: actions/checkout@v1

    - nome: Configurar Nó
      usa: actions/setup-node@v1
      com:
        node-version: '12.1'

    - nome: Dependências de cache
      usa: actions/cache@v1
      com:
        caminho: ./node_modules
        chave: $(( runner.OS ))-dependencies-$(( hashFiles('**/package-lock.json') ))
        chaves de restauração: |
          $(( runner.OS ))-dependencies-$(( env.cache-name ))-
          $(( runner.OS ))-dependencies-
          $(( runner.OS ))-

    - nome: Instalar dependências
      executar: |
        npm install

    - nome: Lintar ficheiros
      executar: |
        npm run lint

O GitHub fornece todo o material ambiental de que precisamos. Na última linha, estamos a executar o comando npm run lint que não estava definido anteriormente:

"scripts": {
    "lint": "npm run lint:js && npm run lint:scss"
}

Note-se que no nosso fluxo de trabalho não estou a utilizar :fix comandos.

Quando todos estes passos estiverem concluídos, pode desfrutar deste belo resultado do GitHub antes de fazer o merge do seu Pull Request: