DEV Community: Vitor DevSP

Padronização de código com (ESLint e EditorConfig)

Vitor DevSP — Wed, 07 Jul 2021 22:07:18 +0000

Utilizando ferramentas que irão aumentar sua produtividade e te proteger de você mesmo.

📌 Índice

Introdução
EditorConfig
ESLint
Prettier
Configurações
- Configurando o EditorConfig
- Configurando o ESLint
Finalizando

✨ Introdução

Por diversas vezes, passei pelo termo padronização de código e ele estava ligado a projetos de empresas com alguns desenvolvedores trabalhando. Com isso, em um primeiro momento, me perguntei: se trabalho sozinho em um projeto, pra que me preocupar em padronizar o código ou os commits (artigo sobre padronização de commits)?!

Inclusive, li um artigo muito bacana sobre isso no IMasters, voltado para a padronização de código em equipes, vou deixar ele AQUI para você conferir depois.

Ao começar a estudar mais padronização de código, me deparei com diversas bibliotecas e configurações que poderia utilizar. Nesse momento, comecei a testar e entender o que é interessante usar em um projeto pessoal e o que pode ficar para outros projetos maiores.

Hoje, estou configurando o ESLint em todos os meus projetos, pois ele acaba ajudando muito na produtividade e com isso consigo manter uma padronização de código entre os meus próprios projetos, o que ajuda muito quando preciso fazer alguma manutenção ou desenvolver novas funcionalidades.

Nesse artigo, falarei sobre as ferramentas e configurações que utilizo atualmente em meus projetos. Deixarei também algumas dicas de configurações que faria para projetos com mais devs.

Primeiramente, contextualizarei sobre as ferramentas que usaremos e depois mostrarei o passo a passo para se fazer as configurações. Dessa maneira, será prático revisitar esse artigo quando precisar criar um projeto e seguir o passo a passo da configuração.

✨ EditorConfig

Existem várias configurações que os editores trazem por padrão, por exemplo:

Se a indentação vai ser feita com espaços ou tabs
O tamanho da indentação, se vai ser de 2 ou 4 espaços por exemplo
O charset que está sendo utilizado
Entre outras...

Em alguns casos, pode acontecer de você utilizar uma indentação de 2 espaços e uma nova página ser criada com 4 espaços ou vice-versa. Esse problema se torna um pouco maior caso haja mais devs no projeto, pois cada um pode preferir uma configuração ou estar utilizando outro editor com configurações diferentes, o que pode bagunçar um pouco o código.

E é aí que entra o EditorConfig. Com ele podemos criar um arquivo de configuração que vai padronizar as configurações entre os editores. Com isso, no projeto em que ele estiver configurado as configurações padrões do editor vão ser substituídas, fazendo com que em qualquer situação tenhamos arquivos padronizados independentemente de gostos ou editores diferentes.

✨ ESLint

O ESLint implementa o processo de Linting, que é responsável por aplicar regras a uma base de código e destacar padrões ou códigos problemáticos, sem a necessidade do código ser executado. No site dele encontramos a descrição "Encontre e corrija problemas em seu código JavaScript", mas ele pode ser usado também com Typescript.

Para podermos usufruir de todo o poder do ESLint é importante seguirmos algum guia de estilo para o nosso código. Dentre os vários guias existentes, um dos mais famosos é o do Airbnb e um que gosto bastante de usar que é o Standard.

Um guia de estilo define regras e padrões que seu código deve seguir. Por exemplo, o guia do Airbnb usa aspas duplas e ponto e vírgula no final da linha. Particularmente, gosto de usar aspas simples e não finalizo a linha com o ponto e vírgula (o código fica muito feio com eles e é totalmente opcional), o que se adequa mais às regras do Standard.

Não existe muito isso de qual é certo ou errado, o importante é você escolher um e seguir. Podemos modificar as regras que vêm por padrão em um guia ou até mesmo criar novas regras, vamos ver isso mais pra frente na seção de configurações.

A coisa que é mais legal depois de configurar o ESLint, motivo por qual eu estou configurando ele em todos os projetos que trabalho, é o fato de conseguimos automatizar boa parte dos ajustes no código, o que agiliza muito na hora de codar.

Uma coisa que me incomodava no auto-import do VS Code, é que às vezes ele faz o import com aspas duplas e ponto e vírgula, quando isso acontecia eu tinha que mudar manualmente as aspas e apagar o ponto e vírgula. Com o ESLint devidamente configurado, basta salvar o arquivo e o código vai ser ajustado automaticamente (isso ajuda muito).

✨ Prettier

Uma outra ferramenta muito utilizada na padronização do código é o Prettier. Ele complementa o ESLint e faz ajustes que ele não faria sozinho. Por exemplo, se você tem uma linha com 100 caracteres ele vai quebrar e indentar a linha automaticamente, trabalhando mais na estrutura do código do que se preocupando com um guia de estilos que ele tenha que seguir.

O Prettier é uma ferramenta fantástica, vou deixar o link da documentação dele AQUI para mais informações. Não vamos configurar ele nesse artigo, geralmente não configuro ele em meus projetos e vou explicar o porque.

Automatizar a organização do código é muito legal e pode ser uma ótima ferramenta, mas isso tira um pouco da sua liberdade e engessa um pouco o código. O Prettier acaba fazendo várias formatações no código e às vezes eu não queria o código com o formato que ele sugeria. Gosto do processo de formatar o código e o Prettier acaba passando um pouco por cima disso. Em projetos que estou trabalhando sozinho, o ESLint é o suficiente para me ajudar, já o trabalho que o Prettier faz, gosto de fazer manualmente.

Então em qual momento eu adicionaria o Prettier em um projeto?

Em projetos Open Source que eu sei que as chances de receber Pull Requests são grandes e se estivesse em uma equipe com outros devs, caso percebesse que nem todos tem a mesma preocupação que eu de deixar o código bonito e organizado. Nesses casos, acho que faz total sentido o uso do Prettier, dessa forma garantimos que todos estão respeitando a organização do código.

✨ Configurações

Será necessário um projeto para fazer a configuração do EditorConfig e ESLint. Você pode seguir esse meu outro artigo para aprender a criar um projeto com Next e Typescript: Iniciando um Projeto com NextJS e Typescript.

Ou pode criar um projeto simples abrindo uma pasta no seu editor e rodando o comando yarn init -y ou npm init -y.

Com o projeto iniciado, podemos começar as configurações.

✨ Configurando o EditorConfig

Para configurar essa ferramenta, iremos precisar de uma extensão do VS Code chamada EditorConfig for VS Code, ela também existe para outros editores.

Com a extensão instalada, podemos clicar com o botão direito sobre o explorador de arquivos do projeto e selecionar a opção Generate .editorconfig e então um arquivo de configuração vai ser criado.

O arquivo vai ser gerado com as seguintes configurações:

root = true

[*]
indent_style = space
indent_size = 2
charset = utf-8
trim_trailing_whitespace = false
insert_final_newline = false

Nesse arquivo podemos ver algumas opções como o tipo de indentação, o tamanho da indentação, qual o charset que está sendo utilizado e algumas outras configurações. Pode ser que o seu indent_size esteja com 4 e não com 2, fica a seu critério modificar essa opção, mas por convenção usamos 2.

Vamos começar modificando as 2 últimas opções, trim_trailing_whitespace e insert_final_newline, de false para true. Trim_trailing_whitespace vai retirar os espaços desnecessários que às vezes deixamos no final da linha ou em uma linha em branco e insert
_final_newline vai adicionar sempre uma linha em branco no final do arquivo, o que deixa o diff do git mais bonito e facilita a inserção de uma nova linha.

Por fim, caso não exista no arquivo, adicionaremos mais uma configuração, a end_of_line = lf, para garantir que as quebras de linha sejam padronizadas. No Windows o final das linhas são representadas por \r\n (um link para quem quiser saber o porquê), já no Linux e Mac são apenas com \n , então para evitar que isso gere algum tipo de problema adicionamos essa configuração.

No final, o seu arquivo deve estar assim:

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

Podemos também fazer a configuração do trim_trailing_whitespace e insert_final_newline direto no VS Code. O EditorConfig busca as configurações do editor para criar o arquivo, dessa maneira não vamos precisar fazer essas modificações quando criamos o próximo arquivo.

Para acessar as configurações do VS Code, digite CTRL+SHIFT+P e pesquise por Open Settings (JSON), clique na opção e irá abrir um arquivo JSON com as configurações do editor.

Basta colocar as seguintes configurações no arquivo e salvar:

"files.insertFinalNewline": true,
"files.trimTrailingWhitespace": true,
// Opcional
"editor.tabSize": 2,
"editor.rulers": [100],

✨ Configurando o ESLint

Antes de iniciar de fato a instalação e configuração do ESLint no nosso projeto, precisamos instalar a extensão do ESLint no VS Code. Ela vai ajudar a fazer com que o código seja ajustado automaticamente e vai destacar os erros que encontrar no nosso código.

Agora, precisamos inserir mais algumas propriedades no arquivo de configuração do editor.

Para acessar as configurações do VS Code, digite CTRL+SHIFT+P e pesquise por Open Settings (JSON), clique na opção e irá abrir um arquivo JSON com as configurações do editor.

Adicione as seguintes linhas no arquivo:

"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
  "source.fixAll": true,
},

Por padrão, o VS Code já tem uma funcionalidade que te ajuda a indentar o código, basta clicar com o botão direito em cima do código e ir na opção Format Document.

Com essas configurações, sempre que salvar um arquivo ele será formatado automaticamente, mesmo não tendo o ESLint instalado. Isso vai te ajudar a manter o código sempre indentado e quando o ESLint estiver configurado, ele já irá formatar seguindo as regras dele.

Agora, vamos para a instalação. As instruções utilizarão o yarn, mas pode ser substituído pelo npm se preferir.

# O -D indica que vamos instalar a lib como uma dependência de desenvolvimento
yarn add eslint -D

# Comando para inicializar o ESLint
yarn eslint --init

O ESLint traz um guia que vai nos ajudar a fazer a instalação, só precisamos responder as perguntas.

1 - How would you like do use Eslint? (Qual a forma que queremos utilizar o Eslint)

To check syntax only ⇒ Checar somente a sintaxe
To check syntax and find problems ⇒ Checar a sintaxe e encontrar problemas
To check syntax, find problems and enforce code style ⇒ Checar a sintaxe, encontrar problemas e forçar um padrão de código

Escolheremos a última opção To check syntax, find problems and enforce code style.

2 - What type of modules does your project use? (Qual tipo de módulo seu projeto usa?)

JavaScript modules (import/export)
CommonsJS (require/exports)

Geralmente vamos utilizar a primeira opção Javascript modules (import/export), a menos que esteja trabalhando em um projeto de Back-end com uma versão do Node que não suporta os Modules, ou em alguma outra situação que demande o uso do CommonsJS.

3 - Which framework does your project use? (Qual framework seu projeto está utilizando?)

React
Vue.JS
None of these

Se for um projeto Back-end escolha a opção None of these. Se estiver criado o projeto seguindo meu artigo de Next.js, escolha React.

4 - Does your project use TypeScript? (Seu projeto está utilizando Typescript?)

No
Yes

Se estiver seguindo meu artigo de Next.js, selecionar a opção Yes.

5 - Where does your code run? (Onde seu código está rodando?)

Browser
Node

Se for um projeto com o Next.js, utilize a tecla Espaço e marque as duas opções.

6 - How would you like to define a style for your project? (Qual guia de estilo queremos utilizar?)

Use a popular style guide ⇒ Padrões de projetos já criados anteriormente por outra empresa
Answer questions about your style ⇒ Criar seu próprio padrão de projeto

Selecione a primeira opção Use a popular style guide

7 - Which style guide do you want to follow? (Qual guia de estilo você deseja seguir?)

Airbnb: https://github.com/airbnb/javascript
Standard: https://github.com/standard/standard
Google: https://github.com/google/eslint-config-google

Selecione a segunda opção Standard. Em um outro momento você pode testar os outros guias.

8 - What format do you want your config file to be in? (Qual formato de configuração do Eslint que você deseja salvar?)

Javascript
YAML
JSON

Selecione a opção JSON.

Nesse ponto, o ESLint irá te informar quais as dependências necessárias de acordo com as opções que foram selecionadas.

9 - Would you like to install them now with npm? (Você deseja instalar as dependências agora utilizando npm?)

Caso esteja utilizando o Npm a resposta é Yes.

Com o Yarn temos duas opções.

A mais simples (ou preguiçosa, geralmente eu uso essa) é responder sim. Desse modo, as dependências serão instaladas com o npm, o que vai fazer com que demore um pouco mais. Ao finalizar, o npm vai criar um arquivo package-lock.json que precisamos apagar, e em seguida precisamos rodar o comando yarn no terminal para mapear as dependências que foram instaladas com o npm no arquivo yarn.lock.
Ou podemos instalar as dependências manualmente. O primeiro passo é selecionar as dependências que apareceram no seu terminal e copiar. No terminal não conseguimos copiar o texto com o atalho CTRL+C precisamos usar CTRL+SHIFT+C ou clicar com o botão direito do mouse e ir em copiar.

Para instalar, começamos com o comando yarn add -D e colamos as dependências que copiamos. O comando vai ter essa estrutura:
```
# Não copie o comando abaixo, é só um exemplo.
# As versões mudam constantemente, use as que esta no seu terminal.

yarn add -D eslint-plugin-react@latest @typescript-eslint/eslint-plugin@latest eslint-config-standard@latest eslint@^7.12.1 eslint-plugin-import@^2.22.1 eslint-plugin-node@^11.1.0 eslint-plugin-promise@^4.2.1 || ^5.0.0 @typescript-eslint/parser@latest
```

Após finalizar a instalação, você vai notar um arquivo .eslintrc.json na raiz do seu projeto. Dentro desse arquivo, no final dele, existe um campo de regras que provavelmente está vazio, vamos adicionar essas regras no arquivo:

"rules": {
  "react/prop-types": "off",
  "react/react-in-jsx-scope": "off",
  "space-before-function-paren": "off",
  "no-console": "warn",
  "comma-dangle": [
    "error",
    "always-multiline"
  ],
  "jsx-quotes": [
    "error",
    "prefer-double"
  ]
}

Vou te explicar as regras, e se quiser mais informações é só pesquisar pela regra no Google.

react/prop-types e react/react-in-jsx-scope são validações do React que não são necessárias, então desativamos elas.
space-before-function-paren, o Standart coloca um espaço entre o nome da função e os parênteses, dessa maneira: function teste () entretanto, não gosto desse padrão então desativo essa regra, assim os parênteses ficam colados no nome da função function teste()
no-console, já aconteceu algumas vezes de eu esquecer algum console.log no código sem querer, em algum teste que estava fazendo. Então passei a configurar essa regra, ela vai gerar um alerta em todos os consoles do código, e com isso eu sempre lembro de retirá-los antes de commitar.
comma-dangle, eu sempre gosto de manter a última vírgula dentro de um objeto JS, pois deixa o diff do git mais bonito e é mais prático para adicionar uma nova propriedade se necessário, essa regra irá sinalizar quando estiver faltando a vírgula.
jsx-quotes, no JS ou TS eu gosto de usar aspas simples, mas no HTML ou JSX eu mantenho as aspas duplas, pra mim faz sentido que seja assim já que o JSX se assemelha muito ao HTML, essa regra sinalizará isso.

Cheguei a ler várias discussões sobre essa regra na internet, alguns consideram uma boa prática, outros não, então fica a seu critério. No final, quando salvar o arquivo, o ESLint vai organizar esses detalhes no código, então é tranquilo.

Pra finalizar, é interessante criar um arquivo .eslintignore e de preferência copiar o conteúdo do arquivo .gitignore do seu projeto e colar nele.

✨ Finalizando

Em um primeiro momento pode parecer muita coisa tudo que vimos, mas não é, só parece porque é algo novo. Quando for fazer a configuração pela segunda vez já vai estar bem mais simples.

Não deixe de fazer essas configurações em um projeto para você testar, garanto que vai te ajudar. Não só vai aumentar a sua produtividade por estar automatizando uma tarefa que está fazendo manualmente (ou pelo menos deveria estar, né 👀), como também vai elevar o nível do seu código, deixando-o mais profissional e mostrando que você se importa com a organização e indentação dele.

Espero que esse artigo tenha somado para você de alguma forma. Você pode entrar em contato comigo para me passar um feedback ou trocar uma ideia pelo Linkedin ou Instagram. Deixarei também o meu GitHub por aqui e meu site vitordevsp.com.br, no qual você pode encontrar mais conteúdos criados por mim.

Padronização de commit com (Commitlint, Husky e Commitizen)

Vitor DevSP — Tue, 15 Jun 2021 15:51:19 +0000

Introduzindo bibliotecas que tornarão seus históricos no Git mais padronizados e manuteníveis.

📌 Índice

Introdução
Commits atômicos
Padronização dos commits
- Conventional Commits na prática
- Semantic Versioning (Versionamento Semântico)
Commitlint
Husky
Commitizen
Instalando e configurando as bibliotecas
- Instalando o commitlint
- Instalando o husky
- Instalando o commitizen
Finalizando

✨ Introdução

Sem dúvidas uma das ferramentas mais importantes para uma pessoa desenvolvedora é o Git. Com essa ferramenta conseguimos fazer o versionamento do nosso código, mantendo um histórico de todas as alterações.

O Git cria uma linha do tempo das modificações feitas em nosso projeto e cada ponto nessa linha do tempo é definido por um commit, que é o ato de empacotar aquelas alterações que foram feitas.

Ao criar um commit, sempre precisamos inserir uma mensagem para o mesmo, que de preferência seja curta, objetiva e descritiva. Se você está aprendendo Git, sua maior preocupação não vai ser criar a melhor mensagem para o seu commit, e nem deveria ser.

Em um primeiro momento, é interessante que você domine as funções básicas do Git, e depois disso dê o próximo passo buscando entender práticas como commits atômicos e padronização das mensagens de commits.

Iniciarei contextualizando sobre as práticas citadas e as bibliotecas que uso para fazer a padronização dos commits e na sequência irei configurar a instalação e configuração das bibliotecas. Dessa maneira, fica mais prático de revisitar o artigo e seguir o passo a passo para configurar futuros projetos.

✨ Commits atômicos

A prática de criar commits atômicos consiste em criar um commit para cada modificação no projeto, por exemplo, vamos imaginar que estamos trabalhando em um projeto e fizemos duas ações:

criamos um novo componente
fizemos alterações em um já existente

Em vez de criarmos um único commit para guardar as alterações que fizemos, faremos dois commits, seguindo um padrão de commits atômicos. O primeiro commit será com os arquivos envolvidos na criação do novo componente, e o segundo com as alterações feitas em um componente já existente.

Dessa maneira conseguimos escrever uma mensagem mais descritiva para o commit, as ações na linha do tempo ficam mais descritivas e é mais prático de navegar pelos commits visualizando as modificações. Na ocorrência de um bug no projeto, é bem mais fácil de encontrar em qual commit ele foi inserido e reverter o que foi feito.

✨ Padronização dos commits

Outra prática muito importante e que está ligada a anterior é a padronização das mensagens dos commits, dessa maneira seguimos uma estrutura na hora de escrevermos as mensagens, o que deixa os commits estruturados e padronizados.

Quando iniciei os estudos com o Git, imaginei se existiria uma regra ou padrão a se seguir ao criar os commits. Esse interesse se despertou a um tempo atrás, quando vi um vídeo no canal do Dev Soutinho falando sobre isso, vou deixar o link para você conferir depois:

Como padronizar commits? #DevTips Conventional Commits + Semantic Release para releases e versioning

Nesse vídeo, o Mario fala sobre o Conventional Commits, vou colar aqui um trecho de descrição do próprio site: "Uma especificação para dar um significado legível às mensagens de commit para humanos e máquinas."

Basicamente, o Conventional Commits é uma convenção que define um conjunto de regras para criar um histórico de commit fácil de ler e padronizado. Essas regras são baseadas na Convenção que foi criada pelo time de desenvolvimento do Angular e passou a ser amplamente utilizado pela comunidade.

OBS: Não existe só a convenção que o time do Angular criou, mas ela é uma das mais utilizadas. Vou deixar o link aqui caso você tenha interesse em ler.

Conventional Commits na prática

O commit tem que seguir a seguinte estrutura:



<tipo>[escopo opcional]: <descrição>

[corpo opcional]

[rodapé(s) opcional(is)]

A mensagem deve ser escrita com letras minúsculas, com um espaço entre o dois pontos e a descrição e sem ponto final.

Geralmente eu escrevo apenas a primeira linha, vou colocar a lista com os tipos que podemos utilizar:

chore: Atualização de tarefas que não ocasionam alteração no código de produção, mas mudanças de ferramentas, mudanças de configuração e bibliotecas.
feat: São adições de novas funcionalidades ou de quaisquer outras novas implantações ao código.
fix: Essencialmente definem o tratamento de correções de bugs.
refactor: Utilizado em quaisquer mudanças que sejam executados no código, porém não alterem a funcionalidade final da tarefa impactada.
docs: Inclusão ou alteração somente de arquivos de documentação.
perf: Uma alteração de código que melhora o desempenho.
style: Alterações referentes a formatações na apresentação do código que não afetam o significado do código, como por exemplo: espaço em branco, formatação, ponto e vírgula ausente etc.
test: Adicionando testes ausentes ou corrigindo testes existentes nos processos de testes automatizados (TDD).
build: Alterações que afetam o sistema de construção ou dependências externas (escopos de exemplo: gulp, broccoli, npm).
ci: Mudanças em nossos arquivos e scripts de configuração de CI (exemplo de escopos: Travis, Circle, BrowserStack, SauceLabs).
env: Utilizado na descrição de modificações ou adições em arquivos de configuração em processos e métodos de integração contínua (CI), como parâmetros em arquivos de configuração de containers.

Exemplos de Commits:

chore: add commitlint e husky
chore(eslint): obrigar o uso de aspas duplas no jsx
refactor: refatorando a tipagem
feat: add axios / buscando e tratando os dados
feat(page/home): criando o roteamentento no next

Dessa maneira fica muito mais fácil a leitura do histórico de commits e o entendimento do que foi feito no código. Se você trabalha sozinho no projeto, experimente ficar 6 meses sem mexer no projeto. Com os commits padronizados, ao voltar a mexer nele, fica muito mais fácil lembrar quais foram suas últimas alterações.

OBS: eu já fiquei perdido no meu próprio código em projetos mais antigos e isso acontece porque ao longo do tempo evoluímos nosso código e adotamos novos hábitos de escrita, ao ponto de não reconhecermos nosso próprio código de meses atrás.

Acabei resumindo o Conventional Commits focando na parte que é mais utilizada, mas separei o link da convenção e de um artigo mais completo sobre o assunto, não deixe de ler:

✨ Semantic Versioning (Versionamento Semântico)

Tanto no vídeo do Mario do canal Dev Soutinho que eu deixei ali em cima, quanto na especificação do Conventional Commits, você vai se deparar com o termo Semantic Versioning.

Ele padroniza o versionamento das bibliotecas que usamos no dia a dia. Estudando-o, você entenderá o porquê dos números que seguem o nome do pacote que você instalou no seu projeto, localizado no arquivo package.json, por exemplo:



"dependencies": {
    "@chakra-ui/react": "^1.6.2",
    "@emotion/react": "^11",
    "@emotion/styled": "^11",
    "framer-motion": "^4",
    "next": "10.2.3",
    "react": "17.0.2",
    "react-dom": "17.0.2"
  }

É muito importante pelo menos entender como funciona o Semantic Versioning, vai te ajudar em diversas situações. Além disso, te ajudará a ter uma compreensão maior na hora de entender o lançamento de uma biblioteca, a evitar uma versão que está com problemas ou entender quando o problema de uma biblioteca foi resolvido. É um conhecimento que só tem a acrescentar na sua vida como dev.

✨ Commitlint

Entendemos o Conventional Commits, mas nada garante que vamos respeitar as regras impostas, pois, mesmo trabalhando sozinho em um projeto, pode ser que esqueçamos de seguir o padrão que foi definido.

É ai que entra o commitlint, com ele conseguimos verificar se a mensagem de commit que escrevemos realmente está dentro dos padrões pré definidos. Vamos usar os padrões do Angular, mas ele pode ser alterado e podemos até mesmo criar o nosso próprio padrão.

Antes de fazermos um commit, vamos rodar a biblioteca para fazer essa verificação. Se a mensagem do commit não estiver seguindo o padrão, será gerado um erro no terminal.

✨ Husky

O Husky vai nos ajudar a criarmos ganchos para o Git de uma maneira simples. Os ganchos são ações que vão ser disparadas em determinados momentos. Nesse caso, vamos criar um gancho para ser disparado antes de um commit ser inicializado.

Dessa maneira, sempre que fizermos um commit, vamos configurar o Husky para executar o Commitlint e verificar se a mensagem do commit está seguindo os padrões recomendados.

Com isso, automatizamos o processo de verificação da mensagem e não precisamos nos preocupar em rodá-lo manualmente. Mesmo com o Commitlint, pode ser que você esqueça de fazer a verificação e não queremos que isso aconteça, mas dessa maneira nenhum commit com a mensagem errada vai passar.

✨ Commitizen

Chegamos na última biblioteca que iremos utilizar.

O Commitizen é uma biblioteca que vai nos ajudar a criar os commits seguindo o padrão do Conventional Commit. Ela gera uma interface no terminal e assim vamos conseguir acessar todos os tipos de commits e suas descrições:

Ao adotar um novo padrão como estamos fazendo, precisamos de um tempo até decorarmos os tipos e não precisar ficar consultando a documentação para conferir qual tipo usar. É aí que essa biblioteca vai nos ajudar.

Iremos criar um script que podemos rodar sempre que quisermos fazer um commit guiado. Dessa maneira, só precisamos seguir o passo a passo que a biblioteca implementa e geraremos um commit dentro do padrão.

Nem sempre vamos precisar usá-la, mas gosto de deixar instalada, pois se precisar é só executar o script.

✨ Instalando e configurando as bibliotecas

Será necessário um projeto para fazer a instalação das bibliotecas. Você pode seguir esse meu outro artigo para aprender a criar um projeto com Next e Typescript:

Iniciando um Projeto com NextJS e Typescript

Ou é só criar um projeto simples com o yarn ou npm, abrindo uma pasta no seu editor e rodando esse comando no terminal:



yarn init -y

# ou 

npm init -y

Com o projeto iniciado, podemos começar a instalar as bibliotecas, todas vão ser instaladas como dependências de desenvolvimento, não vamos usá-las no ambiente de produção.

✨ Instalando o commitlint

Link para o site da biblioteca



# Instalando e configurando o commitlint
yarn add @commitlint/config-conventional @commitlint/cli -D

echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js

Caso você esteja no Windows e a segunda linha der erro, é só criar um arquivo com o nome:

commitlint.config.js

E adicionar esse conteúdo dentro:

module.exports = {extends: ['@commitlint/config-conventional']}

Podemos testar pra ver se deu tudo certo, o primeiro teste precisa gerar um erro porque não está seguindo o padrão do Conventional Commits. O segundo teste deve passar.



# Para testar a biblioteca
echo "teste" | yarn commitlint

echo "feat: teste" | yarn commitlint

✨ Instalando o husky

No site do commitlint vai ter as instruções para instalar o husky também, com yarn ou npm.



# instalando Husky v6
yarn add husky -D

# ativando os hooks
yarn husky install

# Para ativar os hooks automaticamente após a instalação
"scripts": {
  "prepare": "husky install"
}

# Add hook que vai disparar o commitlint
yarn husky add .husky/commit-msg 'yarn commitlint --edit $1'

É muito importante criar o script de prepare no arquivo package.json, caso contrário, quando você ou outra pessoa baixar o projeto do GitHub, o husky não vai funcionar, e então teria que rodar o comando yarn husky install manualmente. Com o script, deixamos essa instalação automatizada.

Agora podemos fazer um commit para verificar se está tudo certo.



# Primeiro precisamos adicionar os arquivos para serem commitados
git add .

# Vamos fazer o commit falhar para ver se tudo está funcionando
# Se o commit passar, algum passo até aqui deu errado
git commit -m "qualquer coisa"

# Agora vamos fazer o commit corretamente, nesse caso eu vou usar o tipo chore
# Por se tratar de uma configuração no ambiente de desenvolvimento
git commit -m "chore: add commitlint e husky"

✨ Instalando o commitizen

Link para o site da biblioteca



# Instalando o commitizen
yarn add commitizen -D

# Criando a configuração
yarn commitizen init cz-conventional-changelog --yarn --dev --exact

# Add um script no package.json para disparar o commitizen
"scripts": {
  "commit": "git-cz"
}

Com a biblioteca instalada e configurada, vamos fazer um commit para entender o passo a passo que ela traz na prática.



# Primeiro, precisamos adicionar os arquivos para serem commitados
git add .

# Agora vamos executar o script para iniciar a biblioteca
yarn commit

Ao iniciar a biblioteca ela vai mostrar um passo a passo:

1) Select the type of change that you're committing: (Use arrow keys)

Selecione o tipo de mudança que você está realizando: (Use as teclas de seta)

É só usar as setas e enter para selecionar um tipo.

2) What is the scope of this change (e.g. component or file name): (press enter to skip)

Qual é o escopo desta mudança (por exemplo, componente ou nome do arquivo): (pressione Enter para pular)

Exemplo: chore(eslint): obrigar o uso de aspas duplas no jsx.

Em vez de colocar na mensagem do commit onde estava sendo feita a modificação, eu passei essa informação no escopo e a mensagem ficou mais sucinta.

3) Write a short, imperative tense description of the change (max 82 chars):

Escreva uma descrição breve e imperativa da mudança (máx. 82 caracteres):

Utilizando o exemplo a cima, essa é a mensagem que sucede o dois pontos: obrigar o uso de aspas duplas no jsx

4) Provide a longer description of the change: (press enter to skip)

Forneça uma descrição mais longa da mudança: (pressione Enter para pular)

Essa opção é opcional e geralmente eu não preencho, mas você pode inserir um contexto mais amplo que descreve a modificação que foi feita.

5) Are there any breaking changes? (y/N)

Existem alterações importantes? (y/N)

A tradução não descreve bem essa opção, ela está ligada a quebra de compatibilidade estipulada pelo Semantic Versioning, se tiver conhecimento sobre isso, vai saber a resposta, senão quer dizer que não está fazendo versionamento e pode pular sem medo.

OBS: Sempre que estiver trabalhando no terminal e ele mostrar duas opções, sendo uma delas maiúscula, se pressionar enter ele seleciona a maiúscula que no caso é o N, ou você pode digitar N e pressionar enter.

6) Does this change affect any open issues? (y/N)

Essa mudança afeta algum problema em aberto? (y/N)

Essa opção está ligada as Issues do GitHub, é uma opção mais avançada e não vou abordá-la nesse artigo, é só pressionar enter.

E pronto, o commit vai ser realizado.

Podemos digitar o comando git log no terminal para ver a lista com os últimos commits, e em primeiro lugar vai estar o commit gerado pelo commitizen.

✨Finalizando

Uma nova prática não precisa e nem deve ser adotada de uma vez em todos os seus projetos. Faça um teste de maneira gradual e analise se faz sentido para o seu contexto. Sempre começo testando algo novo em projetos de estudos.

Uma outra prática interessante é escrever as mensagens dos commits em inglês. Atualmente tenho uma certa dificuldade com o inglês, então prefiro fazer em português nos meus projetos pessoais, para ficar mais claro quando for ler o histórico.

Iniciando um Projeto com Next.js e Typescript

Vitor DevSP — Tue, 08 Jun 2021 18:16:08 +0000

Nesse artigo, falarei um pouco sobre o Next.js e o Typescript, a dupla que estou utilizando em meus novos projetos.

Indice

Introdução
Next.js
- Aprenda mais sobre o Next
Typescript
- Aprenda mais sobre o Typescript
Criando e configurando a aplicação
- Criando um projeto Next.js
- Organizando e limpando a estrutura
Finalizando

Introdução

Nesse artigo, falarei um pouco sobre o Next.js e o Typescript, a dupla que estou utilizando em meus novos projetos.

Começarei contextualizando sobre as tecnologias citadas e recomentando conteúdos nos quais você poderá se aprofundar. Recomendo que posteriormente você revise o artigo, acessando os materiais recomendados.

Por fim, vamos criar e configurar um projeto com o Next.js e o Typescript.

Next.js

O React é uma biblioteca Javascript para construção de interfaces, e não apenas para ambientes web. É possível utilizar o React em aplicações mobile com o React Native, desktop com ElectronJS, e até mesmo em aplicações de Realidade Virtual com o React VR.

O Next é considerado um framework pois adiciona várias funcionalidades em cima do React e algumas delas são:

SSR (Server Side Rendering): Torna a aplicação mais performática para o usuário final e resolve o que pode ser um problema em algumas aplicações, que é a indexação do conteúdo da aplicação por motores de busca, como o Google.
SSG (Static Site Generation): Uma das features mais legais do Next, ele consegue gerar paginas dinâmicas de maneira estática.

Quando estamos usando SSR, sempre que acessamos uma página, ela é gerada novamente pelo servidor, então, mesmo que você tenha uma página que mude uma vez por dia, ainda que seja acessada 1.000 vezes, será renderizada 1.000 vezes pelo servidor. Ou, ainda, se ela acessa o banco de dados, irá acessar 1.000 vezes também.

Com o SSG, podemos configurar o Next para gerar uma página estática e revalidá-la em um intervalo de tempo. Dessa forma, configuramos a nossa página, que muda uma vez por dia, para ser recriada em um intervalo de 24h. Assim, mesmo que ela tenha 10.000 acessos, só será criada uma vez e só fará uma chamada ao banco de dados. Isso é uma funcionalidade incrível.

Para ter mais informações sobre essa feature, deixarei um link de um vídeo da Rockeseat, em que o Diego explora mais essa funcionalidade.

Essa feature fez o Next.js ser o framework mais popular | Code/Drops #59
SPA (Single Page Application): Mesmo com essas features de Backend que vimos até agora, nós não perdemos uma das funcionalidades mais importantes que surgiram com essa onda mais atual de se criar aplicações web.
File System Routing: Em uma aplicação tradicional com React precisamos de uma biblioteca como a react-router-dom para fazer o roteamento das páginas. Por outro lado, o Next, por padrão, cria um roteamento baseado em sistema de arquivos, em que cada arquivo que está dentro da pasta pages automaticamente vira uma rota da aplicação.
Otimização de imagens: O Next tem um componente interno que podemos utilizar para importar imagens de maneira otimizada, com isso podemos obter as imagens com diversos tamanhos e qualidades, prevenindo a importação de imagens pesadas desnecessariamente.

Essas são só algumas das funcionalidades que o Next traz e há um mundo delas para explorar, como Suporte à Internacionalização, Configurações otimizadas, Suporte embutido para CSS e SASS, Envio de arquivo estático, entre outras.

Aprenda mais sobre o Next

No site da Vercel, empresa por trás do Next, temos disponível uma documentação incrível e também um guia com um passo a passo para aprender sobre o framework.

No canal Código Fonte TV, há um vídeo falando sobre o Next.js:

Next.js (Renderização React no Lado Servidor) // Dicionário do Programador

O conteúdo mais legal que eu já vi na internet sobre o Next é uma playlist que o Filipe Deschamps criou no canal dele, você precisa assistir depois que acabar de ler esse post:

Como Criar Um Site (Grátis e Moderno)

E pra quem gosta de ler, tem dois artigos bem interessantes que eu achei enquanto estudava mais para escrever o meu artigo:

Também vou deixar aqui alguns canais que tem conteúdos sobre Next.js, você nunca pode ter uma única fonte de estudos, ainda mais se tratando de programação:

Por fim, não deixe de se inscrever no meu canal. Em breve irei trazer muito conteúdo sobre Next.js e outros tópicos.

Vitor DevSP

Typescript

O Typescript é um conjunto de funcionalidades adicionadas ao Javascript e a principal é trazer a tipagem estática para a linguagem.

O JS é uma linguagem de tipagem fraca, e isso é muito legal, pois te dá muita liberdade para sair programando e traz facilidade para quem está começando a programar. Porém o JS acaba dando liberdade até demais e isso possibilita a criação de erros enquanto programamos, justamente pela tipagem fraca.

Obs: é importante que você saiba JS antes de aprender TS, pois este não é um substituto e sim um complemento.

Quando vi o Typescript pela primeira vez, não gostei nem um pouco dele, eu pensei: como assim ele vai estragar uma das coisas mais legais do JS que é a tipagem fraca. Mas... não é bem por aí.

Quando comprei o Bootcamp da Rocketseat, fui obrigado a estudar Typescript, pois ele estava presente em basicamente todos os módulos. Depois de alguns dias utilizando-o nos estudos, voltei a usar JS nos projetos que estava trabalhando, e então tive um choque de realidade. Foi aí que comecei a perceber na prática como o TS facilitava muito mais a minha vida e, apesar da pequena curva de aprendizado no início, comecei a sentir falta das tipagens sempre que voltava pro JS, principalmente a funcionalidade do autocomplete.

E é aí que entra os pontos mais legais do Typescript:

Autocomplete: como estamos tipando as propriedades que nossos componentes recebem ou as nossas chamadas a APIs, ao acessar um objeto podemos simplesmente usar o CTRL+ESPAÇO para que o autocomplete do VS Code nos ajude a achar a propriedade que queremos. É por meio dele que podemos fazer uma checagem para garantir que não acessaremos um recurso que não existe, e isso é excelente.
Tipagem nas Bibliotecas: em diversos momentos, importamos bibliotecas e nem sempre o autocomplete funciona bem. Usando o Next, por exemplo, em alguns momentos você vai usar uma função padrão que tem métodos ou propriedades pré-definidas.

Nesses casos, podemos importar um conjunto de tipagens de dentro da biblioteca, e ela já vai fornecer todos os métodos e propriedades que aquela função ou objeto tem, o que vai facilitar muito a nossa vida.
Evitar erros de digitação: erro de digitação é algo que é extremamente comum entre os programadores iniciantes, acontecendo até mesmo com programadores mais experientes. O TS vai checar as suas variáveis durante o desenvolvimento, vai identificar todos os possíveis erros e te sinalizar sempre que possível.
Componentes mais consistentes: isso é uma das coisas mais legais. Como podemos tipar as propriedades que um componente vai receber, podemos dizer se elas serão obrigatórias ou não, garantindo que você nunca vai passar uma propriedade errada para dentro de um componente, nem mesmo vai conseguir renderizá-lo com uma propriedade obrigatória faltando.

Resumindo, minha experiência com o TS tem sido incrível. Recentemente tive que fazer modificações em um projeto em javascript de uma cliente e, como fazia um tempo que não tinha contato com ele, tive que primeiro me encontrar no projeto. Com o TS seria bem mais simples de identificar as informações, comportamentos e fazer as alterações necessárias.

Aprenda mais sobre o Typescript

Diferente do que eu imaginava, você não precisa tipar tudo sempre com o TS, ele tenta tipar boa parte das variáveis e retornos de funções. Você consegue deixar muita coisa sem tipar, embora isso não seja o ideal, mas isso ajuda muito nos primeiros projetos, pois você pode ir aprendendo a tipar as coisas aos poucos, que é justamente um dos temas abordados nesse podcast que vou deixar a seguir:

TypeScript vale a pena? JavaScript perde sentido? | Podcast FalaDev #22

Separei um post para você ler sobre typescript. Não deixe de pesquisar por outros se tiver interesse:

TypeScript: Vantagens, mitos, dicas e conceitos fundamentais

E também alguns vídeos:

Pra fechar, separei dois cursos gratuitos de Typescript que estão no Youtube e você pode fazer de graça:

Criando e configurando a aplicação

Existe mais de uma maneira de criar uma aplicação com o Next.js, seguiremos com a recomendada pela Vercel na documentação do Next.

Criando um projeto Next.js

Assim como no CRA, temos um pacote que gera uma aplicação Next configurada para começarmos a programar.

Com o Terminal aberto vamos executar o seguinte comando:

yarn create next-app app-name --typescript

# Caso esteja usando o npm:
npx create-next-app app-name --typescript

Esse comando vai criar uma aplicação com typescript pronta para sairmos programando. Assim que finalizar a criação do projeto, abra ele no seu editor, eu estou usando o vscode.

No terminal, podemos executar o comando yarn dev ou npm run dev para executar um servidor local de desenvolvimento. Depois de executá-lo, ele vai imprimir no console que o projeto esta disponível no localhost:3000. Podemos clicar no link segurando a tecla CTRL ou digitar esse caminho na barra de endereços do navegador.

Organizando e limpando a estrutura

A primeira coisa que eu faço sempre que inicio um projeto é limpar a estrutura dele.

Vamos começar apagando:

O README.md, que está na raiz do projeto.
Os arquivos que estão dentro da pasta styles.
A pasta api que esta dentro da pasta pages.
Vamos apagar também o arquivo vercel.svg de dentro da pasta public e em outro momento iremos substituir o arquivo favicon.ico

Agora criaremos uma pasta src na raiz do projeto e movemos para dentro dela a pasta pages e styles que está na raiz do projeto.

Obs: a pasta pages é rastreada automaticamente pelo Next e os dois únicos lugares que ela pode estar são a raiz ou dentro de src.

Em seguida, precisamos apagar as referências aos arquivos que deletamos.

Dentro de src/pages/_app.tsx apagaremos a importação do CSS.
Dentro de src/pages/index.tsx, apagaremos todas as importações e iremos retornar da função Home apenas um <h1>Hello World</h1>

Como fizemos muitas alterações nos arquivos, vamos reiniciar o servidor que está rodando. Para isso, é só usar o atalho CTRL+C para parar de executá-lo e depois iniciá-lo novamente.

Ao acessar a página no endereço localhost:3000, você deve estar vendo o Hello World que colocamos no arquivo index.

Finalizando

E isso é tudo, pessoal! Muito obrigado por ter me acompanhado até aqui. Não deixe de conferir os links que eu deixei ao longo do artigo, tem muita coisa legal para se consumir.

Espero que esse artigo tenha somado para você de alguma forma. Você pode entrar em contato comigo para me passar um feedback ou trocar uma ideia pelo Linkedin ou Instagram.

E não deixe de me seguir lá no GitHub, sempre estou trabalhando em alguma coisa, você verá meu perfil sem repositórios, mas isso tem um motivo e em breve criarei um post para explicar melhor isso.