eslint config prettier
1.0.0
Отключает все правила, которые не нужны или могут конфликтовать с Prettier.
Это позволяет вам использовать вашу любимую общую конфигурацию, не позволяя ее стилистическому выбору мешать при использовании Prettier.
Обратите внимание, что эта конфигурация только отключает правила, поэтому ее имеет смысл использовать только вместе с какой-либо другой конфигурацией.
Установите eslint-config-prettier:
npm install --save-dev eslint-config-prettier
Добавьте eslint-config-prettier в вашу конфигурацию ESLint — либо в eslintrc, либо в eslint.config.js (плоская конфигурация).
eslintrc: добавьте "prettier" в массив «extends» в вашем файле .eslintrc.* . Обязательно поместите его последним, чтобы он имел возможность переопределить другие конфигурации.
{
"extends" : [
" some-other-config-you-use " ,
" prettier "
]
}eslint.config.js (плоская конфигурация): импортируйте eslint-config-prettier и поместите его в массив конфигурации — после других конфигураций, которые вы хотите переопределить.
import someConfig from "some-other-config-you-use" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
someConfig ,
eslintConfigPrettier ,
] ; Наконец, запустите вспомогательный инструмент CLI, чтобы найти проблемы в разделах "rules" вашей конфигурации.
Используете eslint-plugin-prettier? Ознакомьтесь с рекомендуемой конфигурацией eslint-plugin-prettier.
eslint-config-prettier не только автоматически отключает основные правила, но и некоторые из этих плагинов:
Примечание. В Интернете вы можете найти руководства, в которых говорится, что вам также следует расширять такие вещи, как
"prettier/react". Начиная с версии 8.0.0 eslint-config-prettier, все, что вам нужно расширить, — это"prettier"! Это включает в себя все плагины.
При плоской конфигурации вы сами выбираете имя плагина! Например:
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 ,
] ; Вы могли бы ожидать, что eslint-config-prettier отключит ts/indent , но это не так! Потому что eslint-config-prettier отключает только @typescript-eslint/indent . Он не может знать, как вы решили назвать плагин. То же самое и со вспомогательным инструментом CLI.
Просто придерживайтесь официальных названий плагинов, и все будет хорошо.
Если вы столкнулись с общей конфигурацией , в которой используется нестандартное имя плагина, попросите вместо этого использовать стандартное имя.
Некоторые правила, которые отключает eslint-config-prettier, могут быть устаревшими или даже удалены из ESLint. Это совершенно нормально, но если вам действительно нужно опустить устаревшие и удаленные правила, вы можете сделать это, установив для переменной среды ESLINT_CONFIG_PRETTIER_NO_DEPRECATED непустое значение. Например:
env ESLINT_CONFIG_PRETTIER_NO_DEPRECATED=true npx eslint-find-rules --deprecated index.js
eslint-config-prettier также поставляется с небольшим инструментом CLI, который поможет вам проверить, содержит ли ваша конфигурация какие-либо ненужные или конфликтующие с Prettier правила. Вот как его запустить:
npx eslint-config-prettier path/to/main.js
(Измените path/to/main.js на файл, который существует в вашем проекте.)
Теперь давайте посмотрим, что он делает и почему вы можете его использовать.
В этом примере eslintrc включено конфликтующее правило "indent" :
{
"extends" : [
" some-other-config-you-use " ,
" prettier "
],
"rules" : {
"indent" : " error "
}
} Для eslintrc, хотя "prettier" конфигурация может отключать проблемные правила в "some-other-config-you-use" , она не может касаться "rules" ! (Вот как работает ESLint — он позволяет переопределять расширяемые вами конфигурации.) Вспомогательный инструмент CLI сообщает, что "indent" конфликтует с Prettier, поэтому вы можете удалить его. (Что приятно – упрощает конфигурацию!)
В этом примере eslint.config.js (плоская конфигурация) также включено конфликтующее правило "indent" :
import someConfig from "some-other-config-you-use" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
someConfig ,
eslintConfigPrettier ,
{
rules : {
indent : "error" ,
} ,
} ,
] ;С новым форматом «плоской конфигурации» ESLint вы можете контролировать, какие вещи переопределяют сами. Один из способов решения вышеуказанного конфликта — изменить порядок объектов конфигурации так, чтобы eslint-config-prettier был последним:
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
] ; Однако просмотр приведенной выше конфигурации может показаться запутанным. Похоже, мы включили правило indent , но на самом деле оно отключено благодаря строке eslintConfigPrettier под ним. Вместо этого вы можете захотеть иметь свои собственные правила после eslint-config-prettier и запустить вспомогательный инструмент CLI, чтобы узнать о проблемах, чтобы вы могли полностью удалить конфликтующие правила из файла конфигурации (упрощая вашу конфигурацию).
Теоретически вам необходимо запустить инструмент для каждого отдельного файла в вашем проекте, чтобы быть на 100% уверенным в отсутствии конфликтующих правил, поскольку ESLint поддерживает использование разных правил для разных файлов. Обычно у вас будут примерно одни и те же правила для всех файлов, поэтому достаточно запустить команду для одного файла. Но если вы используете несколько файлов конфигурации или переопределений, вы можете предоставить несколько файлов для проверки:
npx eslint-config-prettier index.js test/index.js legacy/main.js
Как и сам ESLint, вы можете управлять вспомогательным инструментом CLI eslint-config-prettier с помощью переменной среды ESLINT_USE_FLAT_CONFIG :
ESLINT_USE_FLAT_CONFIG=true : используйте только eslint.config.js (плоскую конфигурацию).ESLINT_USE_FLAT_CONFIG=false : используйте только файлы eslintrc.Предупреждение
Для eslint.config.js (плоская конфигурация) вспомогательный инструмент CLI импортируетeslint/use-at-your-own-riskкоторый может сломаться в любой момент.
В версиях eslint-config-prettier до 7.0.0 использовался немного другой инструмент CLI, который запускался по-другому. Например:
npx eslint --print-config index.js | npx eslint-config-prettier-check
Если вы найдете что-то подобное в руководстве, вот как команда выглядит в версии 7.0.0 или новее:
npx eslint-config-prettier index.js
Есть несколько правил, которые eslint-config-prettier отключает, но в некоторых случаях их можно включить.
--fix . Для максимального удобства использования специальные правила по умолчанию отключены (при условии, что вы включили все необходимое в "extends" ). Если они вам нужны, вам необходимо явно указать их в конфигурации ESLint.
Эти правила могут вызвать проблемы при использовании eslint-plugin-prettier и --fix .
Подробности смотрите в arrow-body-style и prefer-arrow-callback .
Есть несколько способов отключить эти правила:
"plugin:prettier/recommended" в "extends" . Это рекомендуемая конфигурация eslint- plugin- prettier."prettier/prettier" в "extends" . (Да, есть как правило "prettier/prettier" , так и конфигурация "prettier/prettier" .) Неважно, какой подход вы используете. "plugin:prettier/recommended" вероятно, самый простой.
Примечание. Инструмент CLI сообщает о них как о проблемах только в том случае, если для того же файла включено правило "prettier/prettier" .
Эти правила можно безопасно использовать, если вы не используете eslint-plugin-prettier. Другими словами, если вы запускаете eslint --fix и prettier --write как отдельные шаги.
Это правило требует определенных опций.
Если блок (например, после if , else , for или while ) содержит только один оператор, JavaScript позволяет опустить фигурные скобки вокруг этого оператора. Это правило применяется в том случае, если или когда эти необязательные фигурные скобки должны быть опущены.
Если вы используете опцию "multi-line" или "multi-or-nest" , правило может конфликтовать с Prettier.
Например, опция "multi-line" позволяет использовать такую строку:
if ( cart . items && cart . items [ 0 ] && cart . items [ 0 ] . quantity === 0 ) updateCart ( cart ) ; Однако Prettier может посчитать строку слишком длинной и превратить ее в следующую, чего не позволяет опция "multi-line" :
if ( cart . items && cart . items [ 0 ] && cart . items [ 0 ] . quantity === 0 )
updateCart ( cart ) ; Если вам нравится это правило, его можно прекрасно использовать с Prettier, если вы не используете опцию "multi-line" или "multi-or-nest" .
Пример конфигурации ESLint:
{
"rules" : {
"curly" : [ " error " , " all " ]
}
}(Следующее также относится и к @typescript-eslint/lines-around-comment.)
Это правило можно использовать с определенными опциями.
Это правило требует пустых строк до и/или после комментариев. Prettier сохраняет пустые строки, за двумя исключениями:
По умолчанию ESLint требует пустую строку над комментарием в этом случае:
if ( result ) {
/* comment */
return result ;
}Однако Prettier удаляет пустую строку:
if ( result ) {
/* comment */
return result ;
}Если вам нравится это правило, его можно прекрасно использовать с Prettier, если вы добавите дополнительную конфигурацию, разрешающую комментарии в начале и конце блоков, объектов и массивов.
Пример конфигурации 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
}
]
}
}(Следующее также относится и к vue/max-len.)
Это правило требует особого внимания при написании кода.
Обычно Prettier автоматически следит за максимальной длиной строки. Однако бывают случаи, когда Prettier ничего не может сделать, например, с длинными строками, регулярными выражениями и комментариями. Их должен разделить человек.
Если вы хотите применить еще более строгую политику максимальной длины строки, чем Prettier может обеспечить автоматически, вы можете включить это правило. Просто не забудьте синхронизировать параметры max-len и параметр printWidth Prettier.
Имейте в виду, что вам, возможно, придется немного реорганизовать код, если Prettier форматирует строки таким образом, который не одобряется правилом max-len .
Пример конфигурации ESLint:
{
"rules" : {
"max-len" : [ " error " , { "code" : 80 , "ignoreUrls" : true }]
}
}Это правило требует определенных опций.
Например, правило могло бы предупреждать об этой строке:
var x = a => 1 ? 2 : 3 ; С помощью {allowParens: true} (по умолчанию, начиная с ESLint 6.0.0) добавление круглых скобок считается допустимым способом избежать путаницы со стрелками:
var x = a => ( 1 ? 2 : 3 ) ;Хотя Prettier сохраняет эти круглые скобки, он удаляет их, если строка достаточно длинная, чтобы ввести разрыв строки:
EnterpriseCalculator . prototype . calculateImportantNumbers = inputNumber =>
1 ? 2 : 3 ; С помощью {allowParens: false} ESLint вместо этого предлагает переключиться на явный возврат:
var x = a => { return 1 ? 2 : 3 ; } ;С Prettier это не вызывает проблем.
Если вам нравится это правило, его можно прекрасно использовать с Prettier, если allowParens отключена.
Пример конфигурации ESLint:
{
"rules" : {
"no-confusing-arrow" : [ " error " , { "allowParens" : false }]
}
} (Примечание. Вспомогательный инструмент CLI считает, что {allowParens: true} является значением по умолчанию, что происходит начиная с ESLint 6.0.0. Инструмент выдаст предупреждение, если вы используете значение по умолчанию, даже если вы используете более старую версию ESLint. Не помешает явно установить {allowParens: false} даже если это технически избыточно. Таким образом, вы будете готовы к будущему обновлению ESLint, и инструмент CLI останется простым.)
Это правило требует особого внимания при написании кода.
Это правило запрещает смешивание определенных операторов, таких как && и || .
Например, правило могло бы предупреждать об этой строке:
var foo = a + b * c ;Правило предлагает добавлять круглые скобки, например:
var foo = a + ( b * c ) ;Однако Prettier удаляет множество «ненужных» скобок, превращая их обратно в:
var foo = a + b * c ;Если вы хотите использовать это правило с Prettier, вам нужно разделить выражение на другую переменную:
var bar = b * c ;
var foo = a + bar ;Однако имейте в виду, что Prettier печатает некоторые «ненужные» круглые скобки:
var foo = ( a && b ) || c ;Пример конфигурации ESLint:
{
"rules" : {
"no-mixed-operators" : " error "
}
}Это правило требует определенных опций.
Это правило запрещает использование символов табуляции. По умолчанию правило запрещает все символы табуляции. Это можно прекрасно использовать с Prettier, если вы не настроили Prettier для отступов с помощью табуляции.
К счастью, можно настроить правило так, чтобы оно работало независимо от того, использует ли Prettier пробелы или табуляции: установите для allowIndentationTabs значение true . Таким образом, Prettier позаботится о ваших отступах, в то время как no-tabs позаботится о потенциальных символах табуляции в любом другом месте вашего кода.
Пример конфигурации ESLint:
{
"rules" : {
"no-tabs" : [ " error " , { "allowIndentationTabs" : true }]
}
}Это правило требует особого внимания при написании кода.
Это правило не позволяет путать многострочные выражения, в которых новая строка выглядит так, будто завершает оператор, но это не так.
Например, правило могло бы предупреждать об этом:
var hello = "world"
[ 1 , 2 , 3 ] . forEach ( addNumber )Prettier обычно форматирует это таким образом, чтобы было очевидно, что точка с запятой отсутствует:
var hello = "world" [ ( 1 , 2 , 3 ) ] . forEach ( addNumber ) ; Однако бывают случаи, когда Prettier разбивает текст на несколько строк, что приводит к конфликтам no-unexpected-multiline .
const value = text . trim ( ) . split ( "n" ) [ position ] . toLowerCase ( ) ;Однако Prettier разбивает его на несколько строк, вызывая конфликт:
const value = text
. trim ( )
. split ( "n" )
[ position ] . toLowerCase ( ) ;Если вам нравится это правило, его обычно можно без проблем использовать с Prettier, но иногда вам может потребоваться либо временно отключить правило, либо выполнить рефакторинг кода.
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 ( ) ;Примечание. Если вы включите это правило, вам придется запустить ESLint и Prettier как два отдельных шага (и сначала ESLint), чтобы получить от него какую-либо ценность. В противном случае Prettier может переформатировать ваш код таким образом, что ESLint никогда не сможет ничего сообщить (как показано в первом примере).
Пример конфигурации:
{
"rules" : {
"no-unexpected-multiline" : " error "
}
}(Следующее также относится к Babel/quotes и @typescript-eslint/quotes.)
Это правило требует определенных параметров и определенных параметров Prettier.
Обычно это правило вообще не требуется. Но есть два случая, когда это может быть полезно:
Если вы хотите, чтобы во всех строках использовались обратные кавычки (а не кавычки), включите опцию "backtick" .
Пример конфигурации ESLint:
{
"rules" : {
"quotes" : [ " error " , " backtick " ]
}
}В следующем примере первый элемент массива можно было бы записать с кавычками вместо обратных кавычек.
const strings = [
`could have been a regular string` ,
`
multiple
lines
` ,
`uses ${ interpolation } ` ,
String . raw `tagged/` ,
] ; Если вы хотите, чтобы ESLint требовал, чтобы `could have been a regular string` записывалась как "could have been a regular string" или 'could have been a regular string' , вам необходимо использовать некоторую конкретную конфигурацию. Правило quotes имеет два параметра: строковый и объектный.
"single" или "double" и синхронизировать его с параметром SingleQuote Prettier."avoidEscape": true для соблюдения правил форматирования строк Prettier."allowTemplateLiterals": false , чтобы запретить ненужные обратные кавычки. ЕСЛинт:
{
"rules" : {
"quotes" : [
" error " ,
" double " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}Prettier (это значение по умолчанию, поэтому добавлять его не требуется):
{
"singleQuote" : false
}ЕСЛинт:
{
"rules" : {
"quotes" : [
" error " ,
" single " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}красивее:
{
"singleQuote" : true
}Это правило можно использовать с определенными опциями.
Это правило автоматически исправляет отступы шаблонов многострочных строк, чтобы они соответствовали коду, в котором они находятся. Настраиваемый белый список используется, чтобы гарантировать, что строки, чувствительные к пробелам, не редактируются.
Prettier имеет дело с:
Использование различных тегов, функций и комментариев.
unicorn/template-indent по умолчанию форматирует некоторые шаблоны с одинаковыми тегами, что может вызвать конфликты. Например, правило и Prettier расходятся во мнениях по поводу отступов в тройных файлах:
condition
? null
: html `
< p >
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam in dui
mauris.
</ p >
` ;Если вам нравится это правило, его можно прекрасно использовать с Prettier, если вы настроите правило так, чтобы оно не обрабатывало те же шаблоны, что и Prettier.
Пример конфигурации ESLint:
{
"rules" : {
"unicorn/template-indent" : [
" error " ,
{
"tags" : [
" outdent " ,
" dedent " ,
" sql " ,
" styled "
],
"functions" : [
" dedent " ,
" stripIndent "
],
"selectors" : [],
"comments" : [
" indent "
]
}
]
}
} Примечание. Если вы используете "selectors" , вспомогательный инструмент CLI не сможет определить, могут ли ваши селекторы вызывать конфликты.
Это правило требует определенных опций.
Это правило определяет, должны ли элементы быть самозакрывающимися или нет.
Prettier обычно сохраняет способ написания элементов:
< div />
< div ></ div >
< MyComponent />
< MyComponent ></ MyComponent >
< svg >< path d = " " /></ svg >
< svg >< path d = " " ></ path ></ svg > Но для известных HTML-элементов void Prettier всегда использует самозакрывающийся стиль. Например, <img> преобразуется в <img /> .
Если вам нравится это правило, его можно прекрасно использовать с Prettier, если вы установите для html.void значение "any" .
Пример конфигурации ESLint:
{
"rules" : {
"vue/html-self-closing" : [
" error " ,
{
"html" : {
"void" : " any "
}
}
]
}
}Эти правила не противоречат Prettier, но имеют некоторые недостатки при использовании с Prettier.
Это правило запрещает использование сбивающего с толку оператора запятой в JavaScript (выражений последовательности). Этот фрагмент кода не делает то, что выглядит:
matrix [ 4 , 7 ] ;Prettier добавляет круглые скобки к приведенному выше, чтобы было понятно, что используется выражение последовательности:
matrix [ ( 4 , 7 ) ] ; Однако правило no-sequences разрешает использовать операторы-запятые, если последовательность выражений явно заключена в круглые скобки. Поскольку Prettier автоматически заключает их в круглые скобки, вы можете никогда не увидеть предупреждений от ESLint об операторах-запятых.
Во время рефакторинга легко может произойти случайное выражение последовательности. Если вы хотите, чтобы ESLint уловил такие ошибки, рекомендуется полностью запретить выражения последовательности, используя синтаксис без ограничений (как указано в документации no-sequences ):
{
"rules" : {
"no-restricted-syntax" : [ " error " , " SequenceExpression " ]
}
} Если вам все еще нужно использовать оператор запятой в каком-то крайнем случае, вы можете разместить комментарий // eslint-disable-next-line no-restricted-syntax в строке над выражением. no-sequences можно безопасно отключить, если вы используете подход no-restricted-syntax .
Вы также можете указать собственное сообщение, если хотите:
{
"rules" : {
"no-restricted-syntax" : [
" error " ,
{
"selector" : " SequenceExpression " ,
"message" : " The comma operator is confusing and a common mistake. Don’t use it! "
}
]
}
}См. package.json для получения точных версий плагинов ESLint, Prettier и ESLint, с которыми тестировался eslint-config-prettier.
Были ли добавлены новые правила после этих версий? Мы пропустили какие-то правила? Есть ли плагин, для которого вы хотели бы видеть исключения? Откройте проблему или запрос на включение!
Если вы хотите добавить поддержку eslint-plugin-foobar, сделайте это следующим образом:
Сначала добавьте правила в index.js :
"foobar/some-rule" : "off" Затем создайте 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 должен завершиться ошибкой при одновременном использовании с eslint-plugin-foobar и eslint-plugin-prettier — до тех пор, пока eslint-config-prettier не будет добавлен в конфигурацию ESLint. Файл должен быть отформатирован в соответствии с Prettier, и это форматирование должно не соответствовать плагину.
Наконец, нужно упомянуть плагин в нескольких местах:
package.json ..eslintrc.base.js и eslint.base.config.js .README.md . Когда вы закончите, запустите npm test , чтобы убедиться, что все сделано правильно. Он запускает несколько других сценариев npm:
"test:prettier" проверяет, что Prettier был запущен для всех файлов."test:eslint" гарантирует, что файлы в test-lint/ передают ESLint при использовании исключений из eslint-config-prettier. Он также анализирует код самого eslint-config-prettier."test:lint-verify-fail" запускается тестом в test/lint-verify-fail.test.js ."test:lint-rules" запускается тестом в test/rules.test.js ."test:jest" запускает модульные тесты, которые проверяют ряд вещей:"test:cli-sanity" и "test:cli-sanity-warning" — это проверки работоспособности CLI. Массачусетский технологический институт.
