Configurar Linting e Git hooks

[imnotteixeira]

Correr o lint no pre commit

[DuarteOliveira8]

Para o lint escolhi usar ESLint e estive à procura de algumas opções de lint específicas para React. Encontrei o eslint-plugin-react que é recomendado pelo ESLint.

Entre as várias opções escolhi algumas que achei necessárias e úteis para manter o nosso código organizado e evitar erros o máximo possível. Isto também vai ajudar pessoal que está a começar a aprender ReactJS, pois evita muitos erros de transição de HTML para JSX.

As opções escolhidas do ESLint foram as seguintes:

• As opções recomendadas pelo ESLint para evitar erros comuns de JavaScript.
• indent: Manter indentação consitente (opção: 4 espaços).
• brace-style: Consistência no brace style (opção: "1tbs").
• camelcase: Usar camel case em todas as variáveis e funções.

As opções escolhidas especificamente para React foram as seguintes:

• react/jsx-no-comment-textnodes: Não fazer commentários de JavaScript em JSX.
• react/jsx-no-duplicate-props: Evitar props duplicadas nos componentes de JSX.
• react/jsx-no-target-blank: Não usar target='_blank' sem rel='noreferrer noopener' pois pode levar a vulnerabilidades.
• react/jsx-no-undef: Evitar componentes JSX não definidos (com a opção "allowGlobals" para considerar o global scope).
• react/jsx-uses-react: Evitar includes de React quando não é necessário.
• react/jsx-uses-vars: Evitar componentes de JSX não usados.
• react/no-children-prop: Não passar children pelas props.
• react/no-deprecated: Evitar a utilização de métodos que já não são suportados pelo React.
• react/no-direct-mutation-state: Apenas modificar o state no construtor ou com setter.
• react/no-unescaped-entities: Evitar caracteres mal posicionados.
• react/no-unknown-property: Evitar usar propriedes da DOM não existentes. Fixable
• react/require-render-return: Obrigar o return na função de render dos componentes.
• react/prop-types: Declarar sempre prop-types para melhorar a reutilização de componentes.
• react/no-unused-prop-types: Evitar declaração de prop-types não usados.
• react/no-unused-state: Evitar declaração de estados não usados.
• react/self-closing-comp: Evitar closing tags a mais em componentes sem children. Fixable
• react/void-dom-elements-no-children: Não colocar children em componentes self-closing.
• react/jsx-closing-tag-location: Reforçar identação dos closing tags. Fixable
• react/jsx-closing-bracket-location: Reforçar a localização do fecho do tag para o caso de elementos que ocupam multiplas linhas. Fixable
• react/jsx-equals-spacing: Evitar espaços antes e depois do = nos elementos de JSX (opção "never"). Fixable
• react/jsx-indent: Reforçar a indentação em JSX (4 espaços). Fixable
• react/jsx-indent-props: Reforçar a indentação das props (4 espaços). Fixable
• react/jsx-max-props-per-line: Limitar numero de props por linhas (opções: 1 prop, multiline). Fixable
• react/jsx-one-expression-per-line: Obrigar a utilização de um tag por linha (opção: "none"). Fixable
• react/jsx-pascal-case: Reforçar a utilização de PascalCase para componentes.

[imnotteixeira]

Até agora, parecem-me bem as rules

Para correr o lint no pre-commit recomendo o husky (https://github.com/typicode/husky), é o que estamos a usar na API-SIGARRA e é muito fácil de configurar

[DuarteOliveira8]

Sim, o António já esteve a ver essa opção! Vamos usar o husky então.

[miguelpduarte]

As rules parecem-me bem. A única que me faz mais comichão seria a do camel case, eu pessoalmente prefiro usar camelCase para funções, PascalCase para classes, e snake_case para variáveis, há forma de pôr isso no eslint? Não havendo, usar camelCase para tudo parece-me uma outra boa opção, mas também podemos debater os coding standards numa reunião ou assim

[miguelpduarte]

Also quero realçar que aprovo bastante o uso de 1tbs hehe

[imnotteixeira]

This might help

https://www.npmjs.com/package/eslint-plugin-more-naming-conventions?activeTab=readme

[DuarteOliveira8]

Pelo que percebi dos exemplos, @imnotteixeira, esse plugin faz com que as funções fiquem em PascalCase e não em camelCase. Mas para variáveis em snake_case é uma boa opção!

Também me apercebi que a opção de camelcase do eslint é só para variáveis. Vou ter de ver melhor opções para naming.

Quanto a classes ficarem em PascalCase, já adicionei isso para os componentes de ReactJS. Acho que não haverá mais classes para além dos componentes, por isso não acho que seja preciso uma opção adicional no eslint, mas posso estar errado.

[imnotteixeira]

pelo que vi do eslint, o camelcase é para vars e funções, o que seria um problema porque ativando os 2 pode dar conflito, mas nada como testar. Seria camelcase para aplicar a vars e funçoes camelcase, e depois o outro do snake case so para vars

[miguelpduarte]

@DuarteOliveira8 Acho que poderiam haver outras "classes" que não seriam components, usadas possivelmente para data processing ou assim. Mas entretanto já pensei nisso e falei também com o @imnotteixeira e ambos concordamos que isso seriam ficheiros de utils standalone que exportariam funções diretamente então seria tranquilo (mesma ideia que ter classes com funções static, mas assim facilitaria importar e afins, imo - se são funcionalmente equivalentes não há razão para complicar com uma classe)

[imnotteixeira]

Done in #6