eslint config prettier
1.0.0
Desativa todas as regras desnecessárias ou que possam entrar em conflito com o Prettier.
Isso permite que você use sua configuração compartilhável favorita sem permitir que suas escolhas estilísticas atrapalhem ao usar o Prettier.
Observe que esta configuração apenas desativa as regras, então só faz sentido usá-la junto com alguma outra configuração.
Instale eslint-config-prettier:
npm install --save-dev eslint-config-prettier
Adicione eslint-config-prettier à sua configuração ESLint – para eslintrc ou para eslint.config.js (configuração simples).
eslintrc: Adicione "prettier" ao array "extends" em seu arquivo .eslintrc.* . Certifique-se de colocá-lo por último, para que tenha a chance de substituir outras configurações.
{
"extends" : [
" some-other-config-you-use " ,
" prettier "
]
}eslint.config.js (configuração simples): importe eslint-config-prettier e coloque-o na matriz de configuração – após outras configurações que você deseja substituir.
import someConfig from "some-other-config-you-use" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
someConfig ,
eslintConfigPrettier ,
] ; Por fim, execute a ferramenta auxiliar CLI para encontrar problemas nas seções "rules" da sua configuração.
Usando eslint-plugin-prettier? Confira a configuração recomendada do eslint-plugin-prettier.
eslint-config-prettier não apenas desativa as regras básicas , mas também alguns desses plug-ins automaticamente:
Nota: Você pode encontrar guias na Internet dizendo que você também deve estender coisas como
"prettier/react". Desde a versão 8.0.0 do eslint-config-prettier, tudo que você precisa estender é"prettier"! Isso inclui todos os plug-ins.
Com a configuração simples, você decide o nome do plugin! Por exemplo:
import typescriptEslint from "@typescript-eslint/eslint-plugin" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
{
plugins : {
// You’d typically use one of the following two:
// typescriptEslint: typescriptEslint,
// typescriptEslint,
// But in this example we give it another name.
// It might be tempting to use something shorter like “ts”:
ts : typescriptEslint , // Don’t do this!
} ,
rules : {
// With eslintrc, this is _always_ called:
// @typescript-eslint/indent
// But in eslint.config.js (flat config), the name chosen above in `plugins` is used.
"ts/indent" : "error" , // Don’t do this!
} ,
} ,
eslintConfigPrettier ,
] ; Você pode esperar que eslint-config-prettier desligue ts/indent , mas isso não acontecerá! Porque eslint-config-prettier apenas desativa @typescript-eslint/indent . Ele não pode saber como você escolheu chamar o plugin. A mesma coisa para a ferramenta auxiliar CLI.
Basta seguir os nomes oficiais dos plugins e você ficará bem.
Se você encontrar uma configuração compartilhada que usa um nome de plug-in não padrão, peça que usem o nome padrão.
Algumas das regras que o eslint-config-prettier desativa podem estar obsoletas ou até mesmo removidas do ESLint. Isso é perfeitamente aceitável, mas se você realmente precisar omitir as regras obsoletas e removidas, poderá fazê-lo definindo a variável de ambiente ESLINT_CONFIG_PRETTIER_NO_DEPRECATED com um valor não vazio. Por exemplo:
env ESLINT_CONFIG_PRETTIER_NO_DEPRECATED=true npx eslint-find-rules --deprecated index.js
eslint-config-prettier também vem com uma pequena ferramenta CLI para ajudá-lo a verificar se sua configuração contém alguma regra desnecessária ou conflitante com o Prettier. Veja como executá-lo:
npx eslint-config-prettier path/to/main.js
(Altere path/to/main.js para um arquivo que existe em seu projeto.)
Agora, vamos dar uma olhada no que ele faz e por que você pode querer usá-lo.
Este exemplo eslintrc tem uma regra conflitante "indent" habilitada:
{
"extends" : [
" some-other-config-you-use " ,
" prettier "
],
"rules" : {
"indent" : " error "
}
} Para eslintrc, embora a configuração "prettier" possa desabilitar regras problemáticas em "some-other-config-you-use" , ela não pode tocar em "rules" ! (É assim que o ESLint funciona – ele permite substituir as configurações que você estende.) A ferramenta auxiliar CLI relata que o "indent" entra em conflito com o Prettier, para que você possa removê-lo. (O que é legal – simplificando sua configuração!)
Este exemplo eslint.config.js (configuração simples) também tem uma regra conflitante "indent" habilitada:
import someConfig from "some-other-config-you-use" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
someConfig ,
eslintConfigPrettier ,
{
rules : {
indent : "error" ,
} ,
} ,
] ;Com o novo formato de “configuração plana” do ESLint, você pode controlar quais coisas substituem o que você mesmo. Uma maneira de resolver o conflito acima é reordenar os objetos de configuração para que eslint-config-prettier seja o último:
import someConfig from "some-other-config-you-use" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
someConfig ,
{
rules : {
indent : "error" ,
} ,
} ,
eslintConfigPrettier , // eslint-config-prettier last
] ; No entanto, olhar para a configuração acima pode parecer confuso. Parece que habilitamos a regra indent , mas na realidade ela está desabilitada graças à linha eslintConfigPrettier abaixo dela. Em vez disso, você pode querer realmente ter suas próprias regras após eslint-config-prettier e executar a ferramenta auxiliar CLI para descobrir os problemas, para que você possa remover completamente as regras conflitantes do arquivo de configuração (simplificando sua configuração).
Em teoria, você precisa executar a ferramenta para cada arquivo do seu projeto para ter 100% de certeza de que não há regras conflitantes, porque o ESLint suporta regras diferentes para arquivos diferentes. Normalmente você terá as mesmas regras para todos os arquivos, então é suficiente executar o comando em um arquivo. Mas se você usar vários arquivos de configuração ou substituições, poderá fornecer vários arquivos para verificação:
npx eslint-config-prettier index.js test/index.js legacy/main.js
Assim como o próprio ESLint, você pode controlar a ferramenta auxiliar CLI eslint-config-prettier usando a variável de ambiente ESLINT_USE_FLAT_CONFIG :
ESLINT_USE_FLAT_CONFIG=true : Use apenas eslint.config.js (configuração simples).ESLINT_USE_FLAT_CONFIG=false : Use apenas arquivos eslintrc.Aviso
Para eslint.config.js (configuração simples), a ferramenta auxiliar CLI importaeslint/use-at-your-own-risk, que pode falhar a qualquer momento.
As versões do eslint-config-prettier anteriores a 7.0.0 tinham uma ferramenta CLI ligeiramente diferente que era executada de maneira diferente. Por exemplo:
npx eslint --print-config index.js | npx eslint-config-prettier-check
Se você encontrar algo assim em um tutorial, o comando se parece com isso na versão 7.0.0 ou posterior:
npx eslint-config-prettier index.js
Existem algumas regras que o eslint-config-prettier desabilita e que na verdade podem ser habilitadas em alguns casos.
--fix . Para máxima facilidade de uso, as regras especiais estão desativadas por padrão (desde que você inclua todos os itens necessários em "extends" ). Se você quiser, você precisa especificá-los explicitamente em sua configuração do ESLint.
Essas regras podem causar problemas ao usar eslint-plugin-prettier e --fix .
Consulte o problema arrow-body-style e prefer-arrow-callback para obter detalhes.
Existem algumas maneiras de desativar essas regras:
"plugin:prettier/recommended" em seu "extends" . Essa é a configuração recomendada do eslint- plugin -prettier."prettier/prettier" em seu "extends" . (Sim, existe uma regra chamada "prettier/prettier" e uma configuração chamada "prettier/prettier" .) Não importa qual abordagem você usa. "plugin:prettier/recommended" é provavelmente o mais fácil.
Nota: A ferramenta CLI só relata isso como problemático se a regra "prettier/prettier" estiver habilitada para o mesmo arquivo.
Essas regras são seguras para uso se você não usar o eslint-plugin-prettier. Em outras palavras, se você executar eslint --fix e prettier --write como etapas separadas.
Esta regra requer certas opções.
Se um bloco (por exemplo, depois de if , else , for ou while ) contém apenas uma instrução, o JavaScript permite omitir as chaves em torno dessa instrução. Esta regra é aplicada se ou quando essas chaves opcionais devem ser omitidas.
Se você usar a opção "multi-line" ou "multi-or-nest" , a regra poderá entrar em conflito com Prettier.
Por exemplo, a opção "multi-line" permite esta linha:
if ( cart . items && cart . items [ 0 ] && cart . items [ 0 ] . quantity === 0 ) updateCart ( cart ) ; Porém, Prettier pode considerar a linha muito longa e transformá-la no seguinte, o que a opção "multi-line" não permite:
if ( cart . items && cart . items [ 0 ] && cart . items [ 0 ] . quantity === 0 )
updateCart ( cart ) ; Se você gosta desta regra, ela pode ser usada perfeitamente com Prettier, desde que você não use a opção "multi-line" ou "multi-or-nest" .
Exemplo de configuração ESLint:
{
"rules" : {
"curly" : [ " error " , " all " ]
}
}(O seguinte também se aplica a @typescript-eslint/lines-around-comment.)
Esta regra pode ser usada com determinadas opções.
Esta regra requer linhas vazias antes e/ou depois dos comentários. Mais bonito preserva linhas em branco, com duas exceções:
Por padrão, o ESLint requer uma linha em branco acima do comentário, neste caso:
if ( result ) {
/* comment */
return result ;
}No entanto, Prettier remove a linha em branco:
if ( result ) {
/* comment */
return result ;
}Se você gostar desta regra, ela pode ser usada perfeitamente com o Prettier, desde que você adicione alguma configuração extra para permitir comentários no início e no final de blocos, objetos e arrays.
Exemplo de configuração ESLint:
{
"rules" : {
"lines-around-comment" : [
" error " ,
{
"beforeBlockComment" : true ,
"afterBlockComment" : true ,
"beforeLineComment" : true ,
"afterLineComment" : true ,
"allowBlockStart" : true ,
"allowBlockEnd" : true ,
"allowObjectStart" : true ,
"allowObjectEnd" : true ,
"allowArrayStart" : true ,
"allowArrayEnd" : true
}
]
}
}(O seguinte também se aplica a vue/max-len.)
Esta regra requer atenção especial ao escrever código.
Normalmente, Prettier se encarrega de seguir automaticamente o comprimento máximo da linha. No entanto, há casos em que Prettier não pode fazer nada, como strings longas, expressões regulares e comentários. Eles precisam ser separados por um humano.
Se desejar impor uma política de comprimento máximo de linha ainda mais rígida do que a que o Prettier pode fornecer automaticamente, você pode ativar esta regra. Apenas lembre-se de manter as opções de max-len e a opção printWidth de Prettier sincronizadas.
Tenha em mente que você pode ter que refatorar um pouco o código se o Prettier formatar as linhas de uma forma que a regra max-len não aprove.
Exemplo de configuração ESLint:
{
"rules" : {
"max-len" : [ " error " , { "code" : 80 , "ignoreUrls" : true }]
}
}Esta regra requer certas opções.
Por exemplo, a regra poderia alertar sobre esta linha:
var x = a => 1 ? 2 : 3 ; Com {allowParens: true} (o padrão desde ESLint 6.0.0), adicionar parênteses é considerado uma forma válida de evitar confusão de setas:
var x = a => ( 1 ? 2 : 3 ) ;Embora Prettier mantenha esses parênteses, ele os removerá se a linha for longa o suficiente para introduzir uma quebra de linha:
EnterpriseCalculator . prototype . calculateImportantNumbers = inputNumber =>
1 ? 2 : 3 ; Com {allowParens: false} , ESLint sugere mudar para um retorno explícito:
var x = a => { return 1 ? 2 : 3 ; } ;Isso não causa problemas com Prettier.
Se você gostar desta regra, ela pode ser usada perfeitamente com Prettier, desde que a opção allowParens esteja desativada.
Exemplo de configuração ESLint:
{
"rules" : {
"no-confusing-arrow" : [ " error " , { "allowParens" : false }]
}
} (Nota: A ferramenta auxiliar CLI considera {allowParens: true} como o padrão, o que é o caso desde o ESLint 6.0.0. A ferramenta produzirá um aviso se você usar o padrão, mesmo se usar uma versão mais antiga do ESLint. Ele não faz mal definir explicitamente {allowParens: false} mesmo que seja tecnicamente redundante. Dessa forma, você está preparado para uma atualização futura do ESLint e a ferramenta CLI pode ser mantida simples.)
Esta regra requer atenção especial ao escrever código.
Esta regra proíbe misturar certos operadores, como && e || .
Por exemplo, a regra poderia alertar sobre esta linha:
var foo = a + b * c ;A regra sugere adicionar parênteses, assim:
var foo = a + ( b * c ) ;No entanto, Prettier remove muitos parênteses “desnecessários”, voltando para:
var foo = a + b * c ;Se quiser usar esta regra com Prettier, você precisa dividir a expressão em outra variável:
var bar = b * c ;
var foo = a + bar ;Tenha em mente que Prettier imprime alguns parênteses “desnecessários”:
var foo = ( a && b ) || c ;Exemplo de configuração ESLint:
{
"rules" : {
"no-mixed-operators" : " error "
}
}Esta regra requer certas opções.
Esta regra não permite o uso de caracteres de tabulação. Por padrão, a regra proíbe todos os caracteres de tabulação. Isso pode ser usado perfeitamente com o Prettier, desde que você não configure o Prettier para recuar usando tabulações.
Felizmente, é possível configurar a regra para que funcione independentemente de Prettier usar espaços ou tabulações: Defina allowIndentationTabs como true . Dessa forma, o Prettier cuida do seu recuo, enquanto o no-tabs cuida dos possíveis caracteres de tabulação em qualquer outro lugar do seu código.
Exemplo de configuração ESLint:
{
"rules" : {
"no-tabs" : [ " error " , { "allowIndentationTabs" : true }]
}
}Esta regra requer atenção especial ao escrever código.
Esta regra não permite expressões confusas de múltiplas linhas em que uma nova linha parece estar encerrando uma instrução, mas não está.
Por exemplo, a regra poderia alertar sobre isso:
var hello = "world"
[ 1 , 2 , 3 ] . forEach ( addNumber )Prettier geralmente formata isso de uma forma que torna óbvio que falta um ponto e vírgula:
var hello = "world" [ ( 1 , 2 , 3 ) ] . forEach ( addNumber ) ; No entanto, há casos em que Prettier divide as coisas em várias linhas, de modo que as no-unexpected-multiline entram em conflito.
const value = text . trim ( ) . split ( "n" ) [ position ] . toLowerCase ( ) ;Prettier divide-o em várias linhas, causando um conflito:
const value = text
. trim ( )
. split ( "n" )
[ position ] . toLowerCase ( ) ;Se você gosta desta regra, ela geralmente pode ser usada com Prettier sem problemas, mas ocasionalmente você pode precisar desabilitar temporariamente a regra ou refatorar seu código.
const value = text
. trim ( )
. split ( "n" )
// eslint-disable-next-line no-unexpected-multiline
[ position ] . toLowerCase ( ) ;
// Or:
const lines = text . trim ( ) . split ( "n" ) ;
const value = lines [ position ] . toLowerCase ( ) ;Nota: Se você habilitar esta regra, você terá que executar ESLint e Prettier como duas etapas separadas (e ESLint primeiro) para obter qualquer valor dela. Caso contrário, Prettier poderá reformatar seu código de tal forma que o ESLint nunca tenha a chance de relatar nada (como visto no primeiro exemplo).
Configuração de exemplo:
{
"rules" : {
"no-unexpected-multiline" : " error "
}
}(O seguinte se aplica a babel/quotes e @typescript-eslint/quotes também.)
Esta regra requer certas opções e certas opções mais bonitas.
Normalmente, você não precisa dessa regra. Mas há dois casos em que pode ser útil:
Se você quiser que todas as strings usem crases (nunca aspas), habilite a opção "backtick" .
Exemplo de configuração ESLint:
{
"rules" : {
"quotes" : [ " error " , " backtick " ]
}
}No exemplo a seguir, o primeiro item da matriz poderia ter sido escrito entre aspas em vez de crases.
const strings = [
`could have been a regular string` ,
`
multiple
lines
` ,
`uses ${ interpolation } ` ,
String . raw `tagged/` ,
] ; Se você quiser que o ESLint imponha `could have been a regular string` sendo escrito como "could have been a regular string" ou 'could have been a regular string' , você precisa usar alguma configuração específica. A regra quotes tem duas opções, uma opção de string e uma opção de objeto.
"single" ou "double" e ser mantida sincronizada com a opção singleQuote do Prettier."avoidEscape": true para seguir as regras de formatação de string do Prettier."allowTemplateLiterals": false para proibir crases desnecessários. ESLint:
{
"rules" : {
"quotes" : [
" error " ,
" double " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}Mais bonito (este é o padrão, portanto não é necessário adicioná-lo):
{
"singleQuote" : false
}ESLint:
{
"rules" : {
"quotes" : [
" error " ,
" single " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}Mais bonito:
{
"singleQuote" : true
}Esta regra pode ser usada com determinadas opções.
Esta regra corrigirá automaticamente o recuo de modelos de string multilinha, para mantê-los alinhados com o código em que são encontrados. Uma lista de permissões configurável é usada para garantir que nenhuma string sensível a espaços em branco seja editada.
Ofertas mais bonitas com:
Usando várias tags, funções e comentários.
unicorn/template-indent por padrão formata alguns dos mesmos modelos marcados, o que pode causar conflitos. Por exemplo, a regra e o Prettier discordam sobre o recuo em ternários:
condition
? null
: html `
< p >
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam in dui
mauris.
</ p >
` ;Se você gostar desta regra, ela pode ser usada perfeitamente com o Prettier, desde que você configure a regra para não lidar com os mesmos modelos do Prettier.
Exemplo de configuração ESLint:
{
"rules" : {
"unicorn/template-indent" : [
" error " ,
{
"tags" : [
" outdent " ,
" dedent " ,
" sql " ,
" styled "
],
"functions" : [
" dedent " ,
" stripIndent "
],
"selectors" : [],
"comments" : [
" indent "
]
}
]
}
} Nota: Se você usar "selectors" , a ferramenta auxiliar CLI não poderá detectar se seus seletores podem causar conflitos.
Esta regra requer certas opções.
Esta regra determina se os elementos devem fechar automaticamente ou não.
Prettier geralmente preserva a maneira como você escreveu seus elementos:
< div />
< div ></ div >
< MyComponent />
< MyComponent ></ MyComponent >
< svg >< path d = " " /></ svg >
< svg >< path d = " " ></ path ></ svg > Mas para elementos HTML vazios conhecidos, Prettier sempre usa o estilo de fechamento automático. Por exemplo, <img> é transformado em <img /> .
Se você gosta desta regra, ela pode ser usada perfeitamente com Prettier, desde que você defina html.void como "any" .
Exemplo de configuração ESLint:
{
"rules" : {
"vue/html-self-closing" : [
" error " ,
{
"html" : {
"void" : " any "
}
}
]
}
}Essas regras não entram em conflito com o Prettier, mas apresentam algumas dicas quando usadas com o Prettier.
Esta regra proíbe o uso do operador vírgula confuso do JavaScript (expressões de sequência). Este pedaço de código não está fazendo o que parece:
matrix [ 4 , 7 ] ;Prettier adiciona parênteses ao texto acima para deixar claro que uma expressão de sequência é usada:
matrix [ ( 4 , 7 ) ] ; No entanto, a regra no-sequences permite operadores de vírgula se a sequência de expressão estiver explicitamente colocada entre parênteses. Como o Prettier os coloca automaticamente entre parênteses, talvez você nunca veja nenhum aviso do ESLint sobre operadores de vírgula.
Terminar com uma expressão de sequência acidental pode acontecer facilmente durante a refatoração. Se você deseja que o ESLint detecte tais erros, é recomendado proibir totalmente as expressões de sequência usando sintaxe sem restrição (conforme mencionado na documentação no-sequences ):
{
"rules" : {
"no-restricted-syntax" : [ " error " , " SequenceExpression " ]
}
} Se você ainda precisar usar o operador vírgula para algum caso extremo, você pode colocar um comentário // eslint-disable-next-line no-restricted-syntax na linha acima da expressão. no-sequences pode ser desativado com segurança se você usar a abordagem no-restricted-syntax .
Você também pode fornecer uma mensagem personalizada se desejar:
{
"rules" : {
"no-restricted-syntax" : [
" error " ,
{
"selector" : " SequenceExpression " ,
"message" : " The comma operator is confusing and a common mistake. Don’t use it! "
}
]
}
}Consulte package.json para as versões exatas dos plug-ins ESLint, Prettier e ESLint com os quais eslint-config-prettier foi testado.
Novas regras foram adicionadas desde essas versões? Perdemos alguma regra? Existe um plugin do qual você gostaria de ver exclusões? Abra um problema ou uma solicitação pull!
Se você quiser adicionar suporte para eslint-plugin-foobar, faça o seguinte:
Primeiro, adicione regras ao index.js :
"foobar/some-rule" : "off" Em seguida, crie test-lint/foobar.js :
/* eslint-disable quotes */
"use strict" ;
// Prettier does not want spaces before the parentheses, but
// `plugin:foobar/recommended` wants one.
console . log ( ) ; test-lint/foobar.js deve falhar quando usado com eslint-plugin-foobar e eslint-plugin-prettier ao mesmo tempo – até que eslint-config-prettier seja adicionado à configuração do ESLint. O arquivo deve ser formatado de acordo com Prettier, e essa formatação deve estar em desacordo com o plugin.
Finalmente, você precisa mencionar o plugin em vários lugares:
package.json ..eslintrc.base.js e eslint.base.config.js .README.md . Quando terminar, execute npm test para verificar se acertou. Ele executa vários outros scripts npm:
"test:prettier" verifica se o Prettier foi executado em todos os arquivos."test:eslint" garante que os arquivos em test-lint/ passem no ESLint quando as exclusões de eslint-config-prettier são usadas. Ele também mostra o próprio código eslint-config-prettier."test:lint-verify-fail" é executado por um teste em test/lint-verify-fail.test.js ."test:lint-rules" é executado por um teste em test/rules.test.js ."test:jest" executa testes unitários que verificam uma série de coisas:"test:cli-sanity" e "test:cli-sanity-warning" são verificações de integridade para a CLI. MIT.
