Até o momento vimos dois posts de introdução ao Webpack, nesse post iremos implementar linters no nosso código JavaScript, se você nunca ouviu falar em linting tools
, elas são ferramentas de optimização de código, elas ajudam-nos a escrever o código organizado e com boas práticas. Mas isso não significa que iremos prevenir bugs, mas a diferença que teremos um código fácil de debugar em grandes times teremos um estilo único de desenvolvimento.
Junto ao linters
responsáveis pela validação básica podemos integrá-los com guias de desenvolvimento, eles utilizam um conjunto de padrões de desenvolvimento para realizar uma validação mais restrita, com isso tempos uma melhor manutenção do nosso código. No mercado front-end temos guias específicos para JavaScript e CSS, muitos guias de CSS estão atrelados a guias visuais, mas também podemos encontrar guias para automatização de validação CSS com Webpack e os principais Guias de estilo do mercado são:
Guias JavaScript
- Airbnb JavaScript style guide – um dos mais populares da internet.
- Google JavaScript style guide – contém os padrões de desenvolvimento do Googles tenta passar informações claras sem afetar a produtividade.
- Standard Style guide – Linter contém função autofix é utilizar por empresas como Zendesk, npm, brave, mongoDB entre outras empresas.
- Idiomatic JavaScript Style guide – tem base o principio todo código base deve parecer como uma única pessoa o codificou, conceito relativo para os outros guias.
Guias CSS/LESS/SASS +HTML
- Fractal – é uma biblioteca de componentes com style guide tempos alguns plugins de integração com webpack.
- Airbnb CSS / SASS Style guide – contém regras de declaração, seletores, formatação, comentários, entre outras regras específicas para SASS
- Indiomatic CSS Principles – contém regras gerais, whitespace, comentários, formatação e uma série de exemplos práticos.
- Stylelint Config Standard – essa configuração estende da configuração recomendada e aplica uma regra de uma série de guias
Por que utilizar Guia de padrão de desenvolvimento ?
Já abordarmos algumas vantagens, mas vale a pena revisar:
- Ajuda na prevenção de erros
- Formatação automática em alguns casos
- Padronização de desenvolvimento
- Facilidade de manutenção de código
- Fácil configuração, uma vez definido o estilo você poderá compartilhar a mesma configuração com o seu time
- Incentivo a boas práticas de desenvolvimento
Ok, Já entendi agora como eu utilizo esses guias com Webpack manter a qualidade do meu código?
Esse tutorial vamos continuar o trabalho no repositório utilizado nos posts anteriores e implementar a validação do nosso código JavaScript, agora vamos criar uma nova branch chamada step-10 para realizarmos os primeiros passos. Inicialmente vamos instalar utilizando o nosso terminal o eslint e eslint-loader no nosso projeto, eles serão os pacotes responsáveis pela validação do nosso código EcmaScript:
npm install eslint-loader eslint --save-dev
Após a instalação dos pacotes precisamos configurar o nosso eslint
, podemos criar o nosso arquivo de configuração .eslintrc
manualmente ou utilizar o terminal para instalação, para facilitar o nosso processo vai utilizar o terminal, para isso executamos o seguinte comando no nosso terminal:
eslint --init
Quando executamos o comando anterior o nosso terminal irá realizar uma série de perguntas que serão elas:
- Como você gostaria de configurar ESLint?
R. Usando um style guide popular - Qual style guide você gostaria de seguir
R. Airbnb - Você usa React?
R. No - Qual o formato que você quer o seu
config file
?
R. JavaScript - Você gostaria de instalar as dependências necessárias?
R. Y(sim)
Feito isso, o arquivo .eslintrc
será criado com o seguinte código:
module.exports = {
"extends": "google"
};
Code language: JavaScript (javascript)
Agora que nos temos o eslint instalado e configurado vamos, incluí-lo no nosso webpack.config.js
:
const path = require('path');
module.exports = {
entry: './src/index.js',
output: {
filename: 'main.js',
path: path.resolve(__dirname, 'dist')
},
module: {
rules: [
{
test: /\.js$/,
exclude: /(node_modules|bower_components)/,
use: [
{
loader: 'babel-loader',
options: {
presets: ['@babel/preset-env'],
},
},
'eslint-loader',
],
},
{
test: /\.(sa|sc|c)ss$/,
exclude: /(node_modules|bower_components)/,
use: [
'style-loader',
'css-loader',
'sass-loader',
],
},
{
test: /\.(svg|gif|png|jpe?g)$/,
loader: 'url-loader',
options: {
limit: 100,
fallback: 'file-loader',
publicPath: '/img',
outputPath: '/img',
},
},
],
},
};
Code language: JavaScript (javascript)
Este é o arquivo de configuração utilizado nos posts anteriores, incluímos o eslint-loader nas nossas regras de leitura para arquivos JavaScript ele agora irá trabalhar em conjunto com o babel loader
.
Rodando o webpack novamente se tudo ocorrer bem teremos o seguinte retorno:
Lendo os nossos errors
e warnings
um ponto de atenção para o document
. O eslint
não reconhece document
porque não especificamos qual ambiente estamos desenvolvendo, para isso vamos fazer uma alteração no nosso arquivo .eslintrc
:
module.exports = {
"extends": "airbnb-base",
"env" : {
"browser": true,
}
};
Code language: JavaScript (javascript)
Com essa nova propriedade “env” definimos browser como true, agora o eslint passará considerar que o nosso será escrito para browsers. Podemos também especificar que o nosso código irá rodar em servidores node.
Rodando nosso código novamente:
Ainda temos alguns erros e warnings podemos resolver de duas maneiras manualmente ou como um autofix, para realizar a correção automática você pode realizar via terminal ou através de configurações no webpack.config.js adicionando opções ao nosso eslint-loader da seguinte forma:
{
test: /\.js$/,
exclude: /(node_modules|bower_components)/,
use: [
{
loader: 'babel-loader',
options: {
presets: ['@babel/preset-env'],
},
},
{
loader: 'eslint-loader',
options: {
fix: true,
},
},
],
},
Code language: CSS (css)
Podemos remover o console.log do nosso código essa é uma ação recomendada, imagina você enviar um código em produção cheio de console.log
, no Webpack podemos definir qual será o modo que iremos trabalhar “development” ou “production” partindo desse princípio podemos. Iremos criar uma condicional no nosso webpack.config quando executarmos o nosso código para produção iremos disparar alertas para remover os console.log
do nosso código.
Para essa etapa iremos trabalhar na branch step-11, primeira mudança vamos incluir dois scripts em nosso package.json:
{
"name": "webpack-tutorial",
"version": "1.0.0",
"description": "Webpack tutorial",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"dev" : "webpack --watch --mode=development",
"build" : "webpack --mode=production"
},
"repository": {
"type": "git",
"url": "git+https://github.com/fellyph/webpack-tutorial.git"
},
"keywords": [
"tutorial",
"webpack"
],
"author": "fellyph",
"license": "ISC",
"bugs": {
"url": "https://github.com/fellyph/webpack-tutorial/issues"
},
"homepage": "https://github.com/fellyph/webpack-tutorial#readme",
"devDependencies": {
"@babel/core": "^7.2.2",
"@babel/preset-env": "^7.3.1",
"babel-loader": "^8.0.5",
"css-loader": "^2.1.0",
"eslint": "^5.15.1",
"eslint-config-airbnb-base": "^13.1.0",
"eslint-config-google": "^0.12.0",
"eslint-loader": "^2.1.2",
"eslint-plugin-import": "^2.16.0",
"file-loader": "^3.0.1",
"node-sass": "^4.11.0",
"sass-loader": "^7.1.0",
"style-loader": "^0.23.1",
"url-loader": "^1.1.2",
"webpack": "^4.29.0",
"webpack-cli": "^3.2.1"
}
}
Code language: JSON / JSON with Comments (json)
Agora temos dois novos scripts dev
e build
, eles incluem o modo que iremos exportar modo de produção irá criar um código minificado sem source map
já o código gerado para desenvolvimento terá recursos que irão facilitar o debug do nosso código.
Quando quisermos exportar a versão de desenvolvimento executamos em nosso terminal o comando:
npm run dev
Ele irá executar o comando webpack --watch --mode=development
assim executaremos o webpack no modo desenvolvimento ainda inclui mais um parâmetro “–watch” para o webpack ficar assistindo todas as mudanças no projeto assim só precisamos rodar o nosso código uma vez. Para exportar o nosso script de produção rodamos o comando:
npm run build
Agora com esses dois novos recursos vamos fazer a seguintes alterações no nosso webpack.config
:
const path = require('path');
module.exports = (env, options) => ({
entry: './src/index.js',
output: {
filename: 'main.js',
path: path.resolve(__dirname, 'dist'),
},
module: {
rules: [
{
test: /\.js$/,
exclude: /(node_modules|bower_components)/,
use: [
{
loader: 'babel-loader',
options: {
presets: ['@babel/preset-env'],
},
},
{
loader: 'eslint-loader',
options: {
fix: true,
rules: {
'no-console': (options.mode === 'development') ? 'off' : 'warn',
},
},
},
],
},
{
test: /\.(sa|sc|c)ss$/,
exclude: /(node_modules|bower_components)/,
use: [
'style-loader',
'css-loader',
'sass-loader',
],
},
{
test: /\.(svg|gif|png|jpe?g)$/,
loader: 'url-loader',
options: {
limit: 100,
fallback: 'file-loader',
publicPath: '/img',
outputPath: '/img',
},
},
],
},
});
Code language: JavaScript (javascript)
Temos várias maneiras de verificar se criamos código para produção ou desenvolvimento, no caso acima converti module.exports
de um objeto para uma função para resgatar o mode
nas opções definidas no nosso código executado no terminal.
Nas opções eslint-loader
adicionamos uma condicional para saber se vamos desligar o alerta para o console.log
, este é um exemplo para uma regra específica, mas podemos colocar qualquer regra dentro dessa condicional todas as regras você pode conferir nesse link
Caso tenha alguma dúvida deixe um comentário ou continue lendo mais tutoriais javascript
Deixe um comentário