eslint config prettier
1.0.0
Desactiva todas las reglas que sean innecesarias o que puedan entrar en conflicto con Prettier.
Esto le permite usar su configuración compartida favorita sin permitir que sus opciones de estilo se interpongan al usar Prettier.
Tenga en cuenta que esta configuración solo desactiva las reglas, por lo que solo tiene sentido usarla junto con alguna otra configuración.
Instale eslint-config-prettier:
npm install --save-dev eslint-config-prettier
Agregue eslint-config-prettier a su configuración de ESLint, ya sea a eslintrc o a eslint.config.js (configuración plana).
eslintrc: agregue "prettier" a la matriz "extendida" en su archivo .eslintrc.* . Asegúrese de ponerlo al final, para que tenga la oportunidad de anular otras configuraciones.
{
"extends" : [
" some-other-config-you-use " ,
" prettier "
]
}eslint.config.js (configuración plana): importe eslint-config-prettier y colóquelo en la matriz de configuración, después de otras configuraciones que desee anular.
import someConfig from "some-other-config-you-use" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
someConfig ,
eslintConfigPrettier ,
] ; Finalmente, ejecute la herramienta auxiliar CLI para encontrar problemas en las secciones de "rules" de su configuración.
¿Usando eslint-plugin-prettier? Consulte la configuración recomendada de eslint-plugin-prettier.
eslint-config-prettier no solo desactiva las reglas principales , sino también algunas de estos complementos automáticamente:
Nota: Es posible que encuentres guías en Internet que indiquen que también debes ampliar cosas como
"prettier/react". Desde la versión 8.0.0 de eslint-config-prettier, ¡todo lo que necesitas ampliar es"prettier"! Eso incluye todos los complementos.
¡Con la configuración plana, puedes decidir el nombre del complemento! Por ejemplo:
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 ,
] ; Es posible que espere que eslint-config-prettier desactive ts/indent , ¡pero no lo hará! Porque eslint-config-prettier solo desactiva @typescript-eslint/indent . No puede saber cómo eligió llamar al complemento. Lo mismo ocurre con la herramienta auxiliar CLI.
Simplemente siga los nombres oficiales de los complementos y todo estará bien.
Si encuentra una configuración compartida que utiliza un nombre de complemento no estándar, pídales que utilicen el nombre estándar en su lugar.
Algunas de las reglas que eslint-config-prettier desactiva pueden quedar obsoletas o incluso eliminarse de ESLint. Esto está perfectamente bien, pero si realmente necesita omitir las reglas obsoletas y eliminadas, puede hacerlo estableciendo la variable de entorno ESLINT_CONFIG_PRETTIER_NO_DEPRECATED en un valor que no esté vacío. Por ejemplo:
env ESLINT_CONFIG_PRETTIER_NO_DEPRECATED=true npx eslint-find-rules --deprecated index.js
eslint-config-prettier también viene con una pequeña herramienta CLI para ayudarlo a verificar si su configuración contiene reglas que sean innecesarias o entren en conflicto con Prettier. Aquí se explica cómo ejecutarlo:
npx eslint-config-prettier path/to/main.js
(Cambie path/to/main.js a un archivo que exista en su proyecto).
Ahora, echemos un vistazo a lo que hace y por qué es posible que desee utilizarlo.
Este ejemplo de eslintrc tiene habilitada una regla conflictiva "indent" :
{
"extends" : [
" some-other-config-you-use " ,
" prettier "
],
"rules" : {
"indent" : " error "
}
} Para eslintrc, si bien la configuración "prettier" puede deshabilitar reglas problemáticas en "some-other-config-you-use" , ¡no puede tocar "rules" ! (Así es como funciona ESLint: le permite anular las configuraciones que extiende). La herramienta auxiliar CLI informa que la "indent" entra en conflicto con Prettier, por lo que puede eliminarla. (Lo cual es bueno: ¡simplificar tu configuración!)
Este ejemplo de eslint.config.js (configuración plana) también tiene habilitada una regla conflictiva "indent" :
import someConfig from "some-other-config-you-use" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
someConfig ,
eslintConfigPrettier ,
{
rules : {
indent : "error" ,
} ,
} ,
] ;Con el nuevo formato de “configuración plana” de ESLint, puedes controlar qué cosas anulan qué tú mismo. Una forma de resolver el conflicto anterior es reordenar los objetos de configuración para que eslint-config-prettier sea el ú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
] ; Sin embargo, mirar la configuración anterior puede resultar confuso. Parece que habilitamos la regla indent , pero en realidad está deshabilitada gracias a la línea eslintConfigPrettier debajo. En su lugar, es posible que desee tener sus propias reglas después de eslint-config-prettier y ejecutar la herramienta auxiliar CLI para conocer los problemas, de modo que pueda eliminar las reglas conflictivas del archivo de configuración por completo (simplificando su configuración).
En teoría, necesitas ejecutar la herramienta para cada archivo de tu proyecto para estar 100% seguro de que no hay reglas en conflicto, porque ESLint admite tener reglas diferentes para diferentes archivos. Por lo general, tendrá aproximadamente las mismas reglas para todos los archivos, por lo que es suficiente ejecutar el comando en un archivo. Pero si utiliza varios archivos de configuración o anulaciones, puede proporcionar varios archivos para verificar:
npx eslint-config-prettier index.js test/index.js legacy/main.js
Al igual que ESLint, puede controlar la herramienta auxiliar CLI eslint-config-prettier utilizando la variable de entorno ESLINT_USE_FLAT_CONFIG :
ESLINT_USE_FLAT_CONFIG=true : utilice únicamente eslint.config.js (configuración plana).ESLINT_USE_FLAT_CONFIG=false : utilice únicamente archivos eslintrc.Advertencia
Para eslint.config.js (configuración plana), la herramienta auxiliar CLI importaeslint/use-at-your-own-risk, que puede fallar en cualquier momento.
Las versiones de eslint-config-prettier anteriores a 7.0.0 tenían una herramienta CLI ligeramente diferente que se ejecutaba de forma diferente. Por ejemplo:
npx eslint --print-config index.js | npx eslint-config-prettier-check
Si encuentra algo así en un tutorial, así es como se ve el comando en 7.0.0 o posterior:
npx eslint-config-prettier index.js
Hay algunas reglas que eslint-config-prettier deshabilita y que en realidad se pueden habilitar en algunos casos.
--fix . Para una máxima facilidad de uso, las reglas especiales están deshabilitadas de forma predeterminada (siempre que incluya todo lo necesario en "extends" ). Si los desea, debe especificarlos explícitamente en su configuración de ESLint.
Estas reglas pueden causar problemas si se usa eslint-plugin-prettier y --fix .
Consulte el problema arrow-body-style y prefer-arrow-callback para obtener más detalles.
Hay un par de formas de desactivar estas reglas:
"plugin:prettier/recommended" en sus "extends" . Esa es la configuración recomendada por eslint- plugin -prettier."prettier/prettier" en tus "extends" . (Sí, hay una regla llamada "prettier/prettier" y una configuración llamada "prettier/prettier" .) No importa qué enfoque utilices. "plugin:prettier/recommended" es probablemente el más fácil.
Nota: La herramienta CLI solo los informa como problemáticos si la regla "prettier/prettier" está habilitada para el mismo archivo.
Estas reglas son seguras de usar si no usas eslint-plugin-prettier. En otras palabras, si ejecuta eslint --fix y prettier --write como pasos separados.
Esta regla requiere ciertas opciones.
Si un bloque (por ejemplo, después de if , else , for o while ) contiene solo una declaración, JavaScript permite omitir las llaves alrededor de esa declaración. Esta regla aplica si se deben omitir esas llaves opcionales y cuándo.
Si utiliza la opción "multi-line" o "multi-or-nest" , la regla puede entrar en conflicto con Prettier.
Por ejemplo, la opción "multi-line" permite esta línea:
if ( cart . items && cart . items [ 0 ] && cart . items [ 0 ] . quantity === 0 ) updateCart ( cart ) ; Sin embargo, Prettier podría considerar la línea demasiado larga y convertirla en lo siguiente, lo que la opción "multi-line" no permite:
if ( cart . items && cart . items [ 0 ] && cart . items [ 0 ] . quantity === 0 )
updateCart ( cart ) ; Si le gusta esta regla, puede usarla perfectamente con Prettier siempre y cuando no use la opción "multi-line" o "multi-or-nest" .
Ejemplo de configuración de ESLint:
{
"rules" : {
"curly" : [ " error " , " all " ]
}
}(Lo siguiente también se aplica a @typescript-eslint/lines-around-comment).
Esta regla se puede utilizar con ciertas opciones.
Esta regla requiere líneas vacías antes y/o después de los comentarios. Prettier conserva líneas en blanco, con dos excepciones:
De forma predeterminada, ESLint requiere una línea en blanco encima del comentario. En este caso:
if ( result ) {
/* comment */
return result ;
}Sin embargo, Prettier elimina la línea en blanco:
if ( result ) {
/* comment */
return result ;
}Si le gusta esta regla, puede usarla perfectamente con Prettier siempre que agregue alguna configuración adicional para permitir comentarios al principio y al final de bloques, objetos y matrices.
Ejemplo de configuración de 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
}
]
}
}(Lo siguiente también se aplica a vue/max-len).
Esta regla requiere especial atención al escribir código.
Por lo general, Prettier se encarga de seguir automáticamente una longitud máxima de línea. Sin embargo, hay casos en los que Prettier no puede hacer nada, como cadenas largas, expresiones regulares y comentarios. Esos deben ser divididos por un humano.
Si desea aplicar una política de longitud máxima de línea aún más estricta que la que Prettier puede proporcionar automáticamente, puede habilitar esta regla. Solo recuerde mantener sincronizadas las opciones de max-len y la opción printWidth de Prettier.
Tenga en cuenta que es posible que deba refactorizar ligeramente el código si Prettier da formato a las líneas de una manera que la regla max-len no aprueba.
Ejemplo de configuración de ESLint:
{
"rules" : {
"max-len" : [ " error " , { "code" : 80 , "ignoreUrls" : true }]
}
}Esta regla requiere ciertas opciones.
Por ejemplo, la regla podría advertir sobre esta línea:
var x = a => 1 ? 2 : 3 ; Con {allowParens: true} (el valor predeterminado desde ESLint 6.0.0), agregar paréntesis se considera una forma válida de evitar la confusión con las flechas:
var x = a => ( 1 ? 2 : 3 ) ;Si bien Prettier mantiene esos paréntesis, los elimina si la línea es lo suficientemente larga como para introducir un salto de línea:
EnterpriseCalculator . prototype . calculateImportantNumbers = inputNumber =>
1 ? 2 : 3 ; Con {allowParens: false} , ESLint sugiere cambiar a un retorno explícito:
var x = a => { return 1 ? 2 : 3 ; } ;Eso no causa problemas con Prettier.
Si le gusta esta regla, puede usarla perfectamente con Prettier siempre que la opción allowParens esté desactivada.
Ejemplo de configuración de ESLint:
{
"rules" : {
"no-confusing-arrow" : [ " error " , { "allowParens" : false }]
}
} (Nota: la herramienta auxiliar CLI considera que {allowParens: true} es el valor predeterminado, como es el caso desde ESLint 6.0.0. La herramienta generará una advertencia si usa el valor predeterminado incluso si usa una versión anterior de ESLint. No está de más establecer explícitamente {allowParens: false} aunque sea técnicamente redundante. De esta manera estará preparado para una futura actualización de ESLint y la herramienta CLI se puede mantener simple).
Esta regla requiere especial atención al escribir código.
Esta regla prohíbe mezclar ciertos operadores, como && y || .
Por ejemplo, la regla podría advertir sobre esta línea:
var foo = a + b * c ;La regla sugiere agregar paréntesis, como este:
var foo = a + ( b * c ) ;Sin embargo, Prettier elimina muchos paréntesis "innecesarios" y los devuelve a:
var foo = a + b * c ;Si desea utilizar esta regla con Prettier, debe dividir la expresión en otra variable:
var bar = b * c ;
var foo = a + bar ;Sin embargo, tenga en cuenta que Prettier imprime algunos paréntesis "innecesarios":
var foo = ( a && b ) || c ;Ejemplo de configuración de ESLint:
{
"rules" : {
"no-mixed-operators" : " error "
}
}Esta regla requiere ciertas opciones.
Esta regla no permite el uso de caracteres de tabulación. De forma predeterminada, la regla prohíbe todos los caracteres de tabulación. Eso se puede usar perfectamente con Prettier siempre y cuando no configures Prettier para sangrar usando pestañas.
Afortunadamente, es posible configurar la regla para que funcione independientemente de si Prettier usa espacios o tabulaciones: establezca allowIndentationTabs en true . De esta manera, Prettier se encarga de tu sangría, mientras que las no-tabs se encargan de los posibles caracteres de tabulación en cualquier otra parte de tu código.
Ejemplo de configuración de ESLint:
{
"rules" : {
"no-tabs" : [ " error " , { "allowIndentationTabs" : true }]
}
}Esta regla requiere especial atención al escribir código.
Esta regla no permite expresiones multilínea confusas en las que una nueva línea parece terminar una declaración, pero no lo es.
Por ejemplo, la norma podría advertir sobre esto:
var hello = "world"
[ 1 , 2 , 3 ] . forEach ( addNumber )Prettier generalmente formatea esto de una manera que hace obvio que falta un punto y coma:
var hello = "world" [ ( 1 , 2 , 3 ) ] . forEach ( addNumber ) ; Sin embargo, hay casos en los que Prettier divide las cosas en varias líneas, de modo que las no-unexpected-multiline entran en conflicto.
const value = text . trim ( ) . split ( "n" ) [ position ] . toLowerCase ( ) ;Sin embargo, Prettier lo divide en varias líneas, lo que provoca un conflicto:
const value = text
. trim ( )
. split ( "n" )
[ position ] . toLowerCase ( ) ;Si le gusta esta regla, generalmente puede usarla con Prettier sin problemas, pero ocasionalmente es posible que necesite desactivar temporalmente la regla o refactorizar su 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: Si habilita esta regla, debe ejecutar ESLint y Prettier como dos pasos separados (y ESLint primero) para obtener algún valor. De lo contrario, Prettier podría reformatear su código de tal manera que ESLint nunca tenga la oportunidad de informar nada (como se ve en el primer ejemplo).
Configuración de ejemplo:
{
"rules" : {
"no-unexpected-multiline" : " error "
}
}(Lo siguiente se aplica también a babel/quotes y @typescript-eslint/quotes).
Esta regla requiere ciertas opciones y ciertas opciones más bonitas.
Por lo general, no necesitas esta regla en absoluto. Pero hay dos casos en los que podría resultar útil:
Si desea que todas las cadenas utilicen comillas invertidas (nunca comillas), habilite la opción "backtick" .
Ejemplo de configuración de ESLint:
{
"rules" : {
"quotes" : [ " error " , " backtick " ]
}
}En el siguiente ejemplo, el primer elemento de la matriz podría haberse escrito entre comillas en lugar de comillas invertidas.
const strings = [
`could have been a regular string` ,
`
multiple
lines
` ,
`uses ${ interpolation } ` ,
String . raw `tagged/` ,
] ; Si desea que ESLint imponga `could have been a regular string` se escriba como "could have been a regular string" o 'could have been a regular string' , debe utilizar alguna configuración específica. La regla quotes tiene dos opciones, una opción de cadena y una opción de objeto.
"single" o "double" y mantenerse sincronizada con la opción singleQuote de Prettier."avoidEscape": true para seguir las reglas de formato de cadenas de Prettier."allowTemplateLiterals": false para no permitir comillas invertidas innecesarias. ESLint:
{
"rules" : {
"quotes" : [
" error " ,
" double " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}Más bonito (este es el valor predeterminado, por lo que no es necesario agregarlo):
{
"singleQuote" : false
}ESLint:
{
"rules" : {
"quotes" : [
" error " ,
" single " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}Más bonita:
{
"singleQuote" : true
}Esta regla se puede utilizar con ciertas opciones.
Esta regla corregirá automáticamente la sangría de las plantillas de cadenas de varias líneas para mantenerlas alineadas con el código en el que se encuentran. Se utiliza una lista blanca configurable para garantizar que no se editen cadenas sensibles a espacios en blanco.
Ofertas más bonitas con:
Usando varias etiquetas, funciones y comentarios.
unicorn/template-indent formatea de forma predeterminada algunas de las mismas plantillas etiquetadas, lo que puede causar conflictos. Por ejemplo, la regla y Prettier no están de acuerdo sobre la sangría en ternarios:
condition
? null
: html `
< p >
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam in dui
mauris.
</ p >
` ;Si le gusta esta regla, puede usarla perfectamente con Prettier siempre que configure la regla para que no utilice las mismas plantillas que Prettier.
Ejemplo de configuración de ESLint:
{
"rules" : {
"unicorn/template-indent" : [
" error " ,
{
"tags" : [
" outdent " ,
" dedent " ,
" sql " ,
" styled "
],
"functions" : [
" dedent " ,
" stripIndent "
],
"selectors" : [],
"comments" : [
" indent "
]
}
]
}
} Nota: Si utiliza "selectors" , la herramienta auxiliar CLI no puede detectar si sus selectores pueden causar conflictos.
Esta regla requiere ciertas opciones.
Esta regla impone si los elementos deben cerrarse automáticamente o no.
Prettier generalmente conserva la forma en que escribiste tus elementos:
< div />
< div ></ div >
< MyComponent />
< MyComponent ></ MyComponent >
< svg >< path d = " " /></ svg >
< svg >< path d = " " ></ path ></ svg > Pero para los elementos HTML vacíos conocidos, Prettier siempre usa el estilo de cierre automático. Por ejemplo, <img> se convierte en <img /> .
Si le gusta esta regla, puede usarla perfectamente con Prettier siempre que establezca html.void en "any" .
Ejemplo de configuración de ESLint:
{
"rules" : {
"vue/html-self-closing" : [
" error " ,
{
"html" : {
"void" : " any "
}
}
]
}
}Estas reglas no entran en conflicto con Prettier, pero tienen algunas trampas cuando se usan con Prettier.
Esta regla prohíbe el uso del confuso operador de coma de JavaScript (expresiones de secuencia). Este fragmento de código no hace lo que parece:
matrix [ 4 , 7 ] ;Prettier agrega paréntesis a lo anterior para dejar claro que se utiliza una expresión de secuencia:
matrix [ ( 4 , 7 ) ] ; Sin embargo, la regla de no-sequences permite operadores de coma si la secuencia de expresión está explícitamente entre paréntesis. Dado que Prettier los envuelve automáticamente entre paréntesis, es posible que nunca vea ninguna advertencia de ESLint sobre los operadores de coma.
Terminar con una expresión de secuencia accidental puede suceder fácilmente durante la refactorización. Si desea que ESLint detecte dichos errores, se recomienda prohibir por completo las expresiones de secuencia que utilicen sintaxis sin restricciones (como se menciona en la documentación no-sequences ):
{
"rules" : {
"no-restricted-syntax" : [ " error " , " SequenceExpression " ]
}
} Si aún necesita usar el operador de coma para algún caso extremo, puede colocar un comentario // eslint-disable-next-line no-restricted-syntax en la línea encima de la expresión. no-sequences se pueden desactivar de forma segura si se utiliza el enfoque no-restricted-syntax .
También puede proporcionar un mensaje personalizado si lo desea:
{
"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 conocer las versiones exactas de los complementos ESLint, Prettier y ESLint con los que se ha probado eslint-config-prettier.
¿Se han agregado nuevas reglas desde esas versiones? ¿Nos hemos saltado alguna regla? ¿Hay algún complemento para el que le gustaría ver exclusiones? ¡Abra una incidencia o una solicitud de extracción!
Si desea agregar soporte para eslint-plugin-foobar, así es como debe hacerlo:
Primero, agregue reglas a index.js :
"foobar/some-rule" : "off" Luego, crea 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 debe fallar cuando se usa con eslint-plugin-foobar y eslint-plugin-prettier al mismo tiempo, hasta que se agregue eslint-config-prettier a la configuración de ESLint. El archivo debe tener el formato Prettier y ese formato no debe coincidir con el del complemento.
Finalmente, debes mencionar el complemento en varios lugares:
package.json ..eslintrc.base.js y eslint.base.config.js .README.md . Cuando haya terminado, ejecute npm test para verificar que lo hizo bien. Ejecuta varios otros scripts npm:
"test:prettier" comprueba que Prettier se haya ejecutado en todos los archivos."test:eslint" se asegura de que los archivos en test-lint/ pasen ESLint cuando se utilizan las exclusiones de eslint-config-prettier. También borra el código del propio eslint-config-prettier."test:lint-verify-fail" se ejecuta mediante una prueba en test/lint-verify-fail.test.js ."test:lint-rules" se ejecuta mediante una prueba en test/rules.test.js ."test:jest" ejecuta pruebas unitarias que verifican una serie de cosas:"test:cli-sanity" y "test:cli-sanity-warning" son comprobaciones de integridad para la CLI. MIT.
