ESLint + StyleLint + Prettier + VSCode para criar a experiência de desenvolvimento front-end mais elegante
introdução
Para uma equipe de front-end madura, os padrões de codificação unificados e os padrões de envio são especialmente importantes. Para garantir ordem, estilo uniforme e ordem, não é de muito valor prático apenas escrever a especificação no documento . Ninguém quer ler as regras uma a uma, memorizá-las e finalmente segui-las ao escrever o código.
Como desenvolver graciosamente e manter o fosso da qualidade do código é uma questão que merece nossa consideração.
Este artigo é uma história paralela do artigo acima. Além do conteúdo do artigo original, o StyleLint é adicionado para verificar o estilo, o Preiiter é adicionado para embelezar o código e cooperar elegantemente com o ESLint e o StyleLint, e a configuração do VSCode é adicionada ao realize todo o conjunto de experiência de desenvolvimento no VSCode Works pronto para uso .
fosso
visão geral
Uma experiência de desenvolvimento ideal pode ser resumida assim:
Preocupe-se apenas com o código comercial, com um fluxo de trabalho elegante , todo o código está no código-fonte durante a depuração e o produto atende aos requisitos de especificação.
No entanto, para atender verdadeiramente aos requisitos da especificação, está longe de ser suficiente confiar apenas nas restrições literais e na conscientização do desenvolvimento. Os métodos de engenharia devem ser usados para permitir que o desenvolvimento use ferramentas automatizadas para concluir os requisitos da especificação durante o processo de desenvolvimento, e o próprio desenvolvimento pode dedicar-se a investir no desenvolvimento de negócios .
**Este artigo combina eslint, stylelint, prettier, vscode, standardjs, husky, lint-staged, commitizen, commitlint e outras ferramentas para construir sistematicamente uma solução de especificação de front-end.
**
A consideração subsequente é escrever todo o conjunto de especificações como uma ferramenta (fosso), que pode ser aplicada a outros projetos de projeto com um clique.
restrições de codificação
A especificação de codificação front-end inclui principalmente duas partes: JS e CSS. ESLint e Stylelint são usados respectivamente em projetos de aterrissagem, e Prettier é combinado para tornar o estilo de codificação uniforme. Como mostrado abaixo:
ESLint + StyleLint + Prettier para completar a automação das restrições de codificação
ESLintName
O projeto integra o ESLint para encontrar e corrigir automaticamente problemas em JavaScript. Onde .eslintrc.js é o arquivo de configuração do eslint. De acordo com diferentes projetos, a configuração será diferente. O conteúdo da configuração usado neste projeto é o seguinte:
module.exports = {
env: {
browser: true,
es2021: true,
},
extends: ['plugin:react/recommended', 'standard', 'plugin:prettier/recommended'],
parser: '@typescript-eslint/parser',
parserOptions: {
ecmaFeatures: {
jsx: true,
},
ecmaVersion: 'latest',
sourceType: 'module',
},
plugins: ['react', '@typescript-eslint'],
rules: {
// eslint 规则写这里
'comma-dangle': ['error', 'only-multiline'],
}
}
Para o significado específico e a função da configuração, consulte a documentação do site oficial [ESLint]( https://github.com/eslint/eslint ).
Os pacotes que precisam ser instalados são:
eslint : entrada do programa ESLint, definido em lint-staged para executar o programa para arquivos JS
eslint-config-standard : um conjunto de configuração geral da regra ESLint.
eslint-config-prettier : Desative as regras do ESLint que podem entrar em conflito com o Prettier e resolva conflitos quando ESLint + Prettier
eslint-plugin-prettier : Plug-in do Prettier, tornando possível usar ESLint + Prettier em combinação. Deixe a operação de formatação do Prettier ser executada no processo de ESLint, e os problemas de formatação encontrados pelo Prettier serão reparados automaticamente no processo de ESLint
Entre eles, eslint-config-standard é um conjunto de configurações de regras ESLint comuns na indústria, fornecidas pelo JavaScript Standard Style. Para regras individuais específicas, consulte: https://standardjs.com/rules.html
Estilo Padrão do JavaScript
O padrão configurado no campo extends no arquivo de configuração ESLint acima indica que as regras para verificação e reparo usam o padrão JavaScript Standard Style
standardjs pode detectar problemas de estilo e programa com antecedência, reduzir o processo de modificação repetida no processo de revisão de código, economizar muito tempo e manter a unidade global.
Por padrão, basta usar o standardjs, não há necessidade de formular regras adicionais, se necessário no desenvolvimento real, pode ser configurado nas regras do .eslintrc.js
StyleLint
Stylelint é um poderoso e avançado verificador de código CSS (linter) que ajuda os desenvolvedores a evitar erros no código CSS e manter um estilo de codificação consistente.
Tem as seguintes funções:
Compreende a sintaxe e os recursos CSS mais recentes (modernos)
Possui mais de 170 regras integradas para detectar erros e impor convenções de codificação
Suporta plug-ins para criar suas próprias regras Corrige
automaticamente a maioria dos problemas de formatação de código Possui uma comunidade crescente e é usado pelo Google, GitHub e WordPress
também pode ser estendido para:
Analisa sintaxe semelhante a CSS, como SCSS, Sass, Less e SugarSS
para extrair código de estilo incorporado de objetos HTML, Markdown e CSS-in-JS e texto de modelo
Os pacotes que precisam ser instalados são:
stylelint : a entrada do programa Stylelint, definida em lint-staged para executar o programa para arquivos de estilo
stylelint-config-standard : o conjunto de configuração de regras acordado pelo Stylelint, Stylelint executa
stylelint-config-prettier de acordo com esta regra : Feche as regras que podem entrar em conflito com o Prettier e resolva o problema de conflito quando Stylelint + Prettier
stylelint-prettier : Plug-in do Prettier, possibilitando o uso do Stylelint + Prettier. Deixe a operação de formatação do Prettier pertencer ao processo Stylelint, e os problemas de formatação encontrados pelo Prettier também serão reparados automaticamente durante o processo Stylelint
Entre eles, stylelint-config-standard é um conjunto de configurações de regras Stylelint em todo o setor. Inclua regras específicas como: Princípios idiomáticos de CSS , Guia de estilo CSS do Google , Guia de estilo do Airbnb e Guia de código do @mdo .
mais bonita
Prettier é uma ferramenta de formatação de código de "atitude" que suporta um grande número de linguagens de programação. Comparado com o ESLint (que se concentra principalmente em erros gramaticais e faz alguma formatação), ele se concentra mais no estilo e no estilo do código. Portanto, é necessário usar Prettier e ESLint juntos no desenvolvimento diário para ficar elegante e impecável.
Para configuração deste projeto, consulte o arquivo prettier.config.js
Os pacotes que precisam ser instalados são:
comprometer restrições
A configuração de ESLint + Stylelint + Prettier é concluída acima, e yarn eslint xx.tsx, yarn stylelint xx.less, yarn prettier xx.md , etc. podem ser usados no projeto para verificar e reparar diferentes arquivos. No entanto, não é realista confiar no desenvolvimento para executar comandos manualmente, e ainda são necessários métodos de engenharia para ajudar o desenvolvimento a ser concluído automaticamente .
O seguinte descreve o uso de husky + lint-staged + commitizen + commitlint para executar automaticamente a verificação e o reparo ao enviar e, ao mesmo tempo, restringir o formato do próprio envio. O processo principal é mostrado na figura abaixo:
Enviar diagrama de processo principal de restrição
comprometer
Commitizen é uma ferramenta para formatar mensagens de confirmação do git, que fornece uma maneira de estilo de consulta para obter as informações de confirmação necessárias.
Envio de consulta
cz-conventional-changelog é usado para especificar quais informações precisam ser inseridas ao enviar, como se o tipo de envio é para reparar problemas ou desenvolvimento de função, o escopo do impacto do envio, etc. cz-conventional-changelog é uma regra fornecida pelo site oficial. Você mesmo pode desenvolver regras adequadas de acordo com a situação real do projeto, mas elas são suficientes nesta fase, e não há necessidade de modificá-las.
Como a plataforma Windows não oferece suporte à multiplexação git commit para enviar, ela pode ser enviada por meio do comando cz script em package.json
// package.json
"scripts": {
"cz": "git-cz"
}
Em essência, execute o comando git-cz no diretório raiz do projeto a ser enviado, para que você possa usar qualquer um dos yarn cz**, yarn git-cz , npm run cz , **npx git-cz para concluir seu envio .
Os pacotes que precisam ser instalados são:
commitizen
cz-conventional-changelog
husky + estágio de fiapos
husky é uma ferramenta para processar git hooks, que pode interceptar git hooks e possibilitar " verificar o formato de envio ", " verificar o código " e assim por diante.
lint-staged é uma ferramenta para operações de lint na área de preparação. Primeiro, economiza tempo por não precisar lint o código global a cada vez; segundo, ao aplicar as regras do lint a projetos antigos, todas as submissões não podem passar devido a razões históricas, então também é necessário lint apenas o código que está prestes a ser submetido.
Para obter instruções de uso da ferramenta, consulte: husky
Use a ferramenta Lint-stage em combinação para detectar apenas a peça atualmente modificada.
// package.json
"lint-staged": {
"*.{js,jsx,ts,tsx}": [
"eslint --fix"
],
"*.{less,css}": [
"stylelint --fix"
]
}
Depois de instalar o husky, haverá uma pasta .husky adicional no diretório raiz do projeto para a configuração de ganchos git. Ao mesmo tempo, adicione a configuração lint-staged em package.json, conforme mostrado acima, ao enviar js, jsx , ts, tsx Use eslint automaticamente para verificação e reparo automático e, para less e css, use styleint automaticamente para verificação e reparo ao enviar.
Somente o código passado será enviado, caso haja algo que não atenda as especificações, será reportado um erro no envio, podendo ser reparado conforme necessário.
Os pacotes que precisam ser instalados são:
husky : lidar com ganchos git
lint-stage : válido apenas para a área de preparação
O uso de husky+lint-staged interceptará e reparará automaticamente ao enviar. Se os erros puderem ser solicitados em tempo real durante o desenvolvimento e os erros puderem ser reparados automaticamente ao salvar, você poderá evitar o problema de reparar erros intensivamente ao enviar. Para saber como implementar, consulte o capítulo de configuração do projeto.
commitlint
O método de envio no estilo de consulta é implementado por meio do commit acima, mas não há como garantir que o desenvolvimento obedecerá a este acordo. Para evitar erros de desenvolvimento, use git commit para enviar o código você mesmo, então use commitlint para verificar o informações de envio antes de enviá-las para o depósito.
commitlint é uma ferramenta para verificar se os commits estão de acordo com a especificação.
Os pacotes de instalação necessários são:
@commitlint/cli : Commitlint, a entrada de execução para verificação, é usado em conjunto com husky para usar o gancho git de commmit-msg para verificar as informações de envio ao enviar o código. Se não atender às especificações de envio, uma mensagem de erro será relatado.
@commitlint/config-conventional Um conjunto de esquemas comuns de verificação de informações de envio, produzidos pela equipe Angular. Você também pode personalizar as especificações de sua própria equipe, se necessário.
Configuração de engenharia
O padrão e as ferramentas de verificação foram implantados anteriormente, e o envio também foi interceptado, o que já pode garantir a qualidade do código. Mas, para melhorar ainda mais a eficiência do desenvolvimento, não queremos encontrar muitos erros de verificação ao enviar.
O seguinte usa o vscode como um exemplo para realizar a função de solicitar erros em tempo real durante o processo de desenvolvimento e formatar e reparar automaticamente com um clique , de modo a obter um uso pronto para uso consistente para todos os desenvolvimentos.
Outros editores são semelhantes, você pode consultar a configuração de seus respectivos editores
plug-in do VSCode
Se você deseja que o editor indique erros automaticamente e os corrija automaticamente durante o desenvolvimento, certifique-se de instalar o plug-in ESLint e o plug-in StyleLint
Os plug-ins dos quais o projeto depende são configurados em .vscode/extensions.json. Se houver novos plug-ins dependentes no futuro, eles poderão ser configurados aqui e enviados para garantir que todos os desenvolvedores confiem na unificação de plug-ins ins.
{
"recommendations": ["dbaeumer.vscode-eslint", "stylelint.vscode-stylelint"]
}
Atualmente, apenas ESLint e StyleLint são necessários.
Após a instalação do plug-in, para erros no código, será exibida uma mensagem de erro conforme a figura a seguir:
Citado de Modern.js, invadido e deletado
Ao mesmo tempo, há dicas no nome do arquivo e na caixa de visualização à direita, que chamam a atenção.
Configuração do VSCode
A configuração do vscode da qual o projeto depende está em .vscode/setting.json, e são essas configurações que permitem " editar o erro em tempo real ", " reparar automaticamente ao salvar " e " reparar automaticamente ao corrigir clicando para formatar o arquivo ".
Depois de instalar o plug-in, você precisa configurá-lo de acordo para se adaptar às diferentes necessidades de desenvolvimento.
Por exemplo, é necessário definir as ferramentas de formatação padrão de typescript, javascript, typescriptreact, javascriptreact e outros arquivos para reparo automático de eslint. Dessa forma, nesses arquivos, clique com o botão direito do mouse - formate o documento para invocar automaticamente o eslint para verificação e formatação.
StyleLint é configurado da mesma maneira.
A configuração do projeto neste artigo é a seguinte, e o lint automático ao salvar está ativado, para que ao salvar o arquivo todas as verificações e reparos sejam concluídos automaticamente.
{
"eslint.run": "onType",
"eslint.codeActionsOnSave.mode": "all",
"eslint.format.enable": true, // 允许eslint 格式化对应的文件
"[typescript]": {
"editor.defaultFormatter": "dbaeumer.vscode-eslint",
"editor.codeActionsOnSave": {
// 开启保存时执行eslint进行校验和格式化
"source.fixAll.eslint": true
},
"editor.formatOnSave": false // 所以编辑器默认的格式化设置为false，避免重复格式化
},
"[javascript]": {
"editor.defaultFormatter": "dbaeumer.vscode-eslint",
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
},
"editor.formatOnSave": false
},
"[typescriptreact]": {
"editor.defaultFormatter": "dbaeumer.vscode-eslint",
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
},
"editor.formatOnSave": false
},
"[javascriptreact]": {
"editor.defaultFormatter": "dbaeumer.vscode-eslint",
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
},
"editor.formatOnSave": false
},
"[sass]": {
"editor.defaultFormatter": "stylelint.vscode-stylelint", // 设置编辑器默认格式化工具为stylelint
"editor.codeActionsOnSave": {
"source.fixAll.stylelint": true // 保存时自动使用sytlelint 修复
},
"editor.formatOnSave": false // 关闭编辑器默认的保存格式化
},
"[css]": {
"editor.defaultFormatter": "stylelint.vscode-stylelint",
"editor.codeActionsOnSave": {
"source.fixAll.stylelint": true
},
"editor.formatOnSave": false
},
"[less]": {
"editor.defaultFormatter": "stylelint.vscode-stylelint",
"editor.codeActionsOnSave": {
"source.fixAll.stylelint": true
},
"editor.formatOnSave": false
}
}
Resumir
Por fim, espero que todos os armazéns frontais defendam a cidade com sucesso!