eslint config prettier
1.0.0
불필요하거나 Prettier와 충돌할 수 있는 모든 규칙을 끕니다.
이를 통해 Prettier를 사용할 때 스타일 선택을 방해하지 않고 즐겨 사용하는 공유 가능한 구성을 사용할 수 있습니다.
이 구성은 규칙 만 끄 므로 다른 구성과 함께 사용하는 것이 합리적입니다.
eslint-config-prettier를 설치합니다:
npm install --save-dev eslint-config-prettier
eslintrc 또는 eslint.config.js(플랫 구성)에 ESLint 구성에 eslint-config-prettier를 추가합니다.
eslintrc: .eslintrc.* 파일의 "extends" 배열에 "prettier" 추가합니다. 마지막 에 넣어야 다른 구성을 재정의할 수 있습니다.
{
"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"와 같은 항목도 확장해야 한다는 가이드를 찾을 수 있습니다. eslint-config-prettier 버전 8.0.0부터 확장해야 할 것은"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에는 구성에 불필요하거나 Prettier와 충돌하는 규칙이 포함되어 있는지 확인하는 데 도움이 되는 작은 CLI 도구도 함께 제공됩니다. 실행 방법은 다음과 같습니다.
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 도우미 도구를 실행하여 문제를 알아낼 수 있으므로 구성 파일에서 충돌하는 규칙을 완전히 제거할 수 있습니다(구성 단순화).
이론상으로 ESLint는 서로 다른 파일에 대해 서로 다른 규칙을 지원하므로 충돌하는 규칙이 없는지 100% 확신하기 위해 프로젝트의 모든 단일 파일에 대해 도구를 실행해야 합니다. 일반적으로 모든 파일에 대해 동일한 규칙이 적용되므로 하나의 파일에 대해 명령을 실행하는 것으로 충분합니다. 그러나 여러 구성 파일이나 재정의를 사용하는 경우 확인할 여러 파일을 제공할 수 있습니다.
npx eslint-config-prettier index.js test/index.js legacy/main.js
ESLint 자체와 마찬가지로 ESLINT_USE_FLAT_CONFIG 환경 변수를 사용하여 eslint-config-prettier CLI 도우미 도구를 제어할 수 있습니다.
ESLINT_USE_FLAT_CONFIG=true : eslint.config.js(플랫 구성)만 사용하세요.ESLINT_USE_FLAT_CONFIG=false : eslintrc 파일만 사용합니다.경고
eslint.config.js(플랫 구성)의 경우 CLI 도우미 도구는 언제든지 중단될 수 있는eslint/use-at-your-own-risk가져옵니다.
7.0.0 이전의 eslint-config-prettier 버전에는 다른 방식으로 실행되는 약간 다른 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 문제를 참조하세요.
이러한 규칙을 해제하는 방법에는 두 가지가 있습니다.
"extends" 에 "plugin:prettier/recommended" 입력하세요. 이것이 eslint- plugin -prettier의 권장 구성입니다."extends" 에 "prettier/prettier" 입력하세요. (예, "prettier/prettier" 라는 규칙 과 "prettier/prettier" 라는 구성이 모두 있습니다.) 어떤 접근 방식을 사용하는지는 중요하지 않습니다. "plugin:prettier/recommended" 아마도 가장 쉬울 것입니다.
참고: CLI 도구는 동일한 파일에 대해 "prettier/prettier" 규칙이 활성화된 경우에만 이를 문제가 있는 것으로 보고합니다.
eslint-plugin-prettier를 사용하지 않는 경우에도 이러한 규칙을 사용해도 안전합니다. 즉, eslint --fix 와 prettier --write 별도의 단계로 실행하는 경우입니다.
이 규칙에는 특정 옵션이 필요합니다.
블록(예: after 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 ) ; 이 규칙이 마음에 들면 "multi-line" 또는 "multi-or-nest" 옵션을 사용하지 않는 한 Prettier에서 잘 사용할 수 있습니다.
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 의 옵션과 Prettier의 printWidth 옵션을 동기화 상태로 유지하는 것을 기억하세요.
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에서는 문제가 발생하지 않습니다.
이 규칙이 마음에 들면, allowParens 옵션이 꺼져 있는 한 Prettier에서 잘 사용할 수 있습니다.
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" 로 설정해야 하며 Prettier의 SingleQuote 옵션과 동기화를 유지해야 합니다."avoidEscape": true ."allowTemplateLiterals": false . ESL린트:
{
"rules" : {
"quotes" : [
" error " ,
" double " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}Prettier(기본값이므로 추가할 필요가 없음):
{
"singleQuote" : false
}ESL린트:
{
"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 > 그러나 알려진 void HTML 요소의 경우 Prettier는 항상 자체 닫는 스타일을 사용합니다. 예를 들어 <img> <img /> 로 변환됩니다.
이 규칙이 마음에 든다면 html.void "any" 로 설정하는 한 Prettier에서 잘 사용할 수 있습니다.
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-restricted-syntax( no-sequences 문서에서 언급한 대로)를 사용하여 시퀀스 표현식을 완전히 금지하는 것이 좋습니다.
{
"rules" : {
"no-restricted-syntax" : [ " error " , " SequenceExpression " ]
}
} 일부 특수한 경우에 여전히 쉼표 연산자를 사용해야 하는 경우 표현식 위 줄에 // eslint-disable-next-line no-restricted-syntax 주석을 배치할 수 있습니다. no-restricted-syntax 접근 방식을 사용하면 no-sequences 안전하게 비활성화할 수 있습니다.
원하는 경우 사용자 정의 메시지를 제공할 수도 있습니다.
{
"rules" : {
"no-restricted-syntax" : [
" error " ,
{
"selector" : " SequenceExpression " ,
"message" : " The comma operator is confusing and a common mistake. Don’t use it! "
}
]
}
}eslint-config-prettier가 테스트된 ESLint, Prettier 및 ESLint 플러그인의 정확한 버전은 package.json을 참조하세요.
해당 버전 이후 새로운 규칙이 추가되었나요? 우리가 놓친 규칙이 있나요? 제외하고 싶은 플러그인이 있나요? 이슈나 풀 리퀘스트를 열어보세요!
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 ( ) ; eslint-config-prettier가 ESLint 구성에 추가될 때까지 eslint-plugin-foobar 및 eslint-plugin-prettier와 동시에 사용하면 test-lint/foobar.js 실패해야 합니다. 파일 형식은 Prettier에 따라 지정되어야 하며 해당 형식은 플러그인과 일치하지 않아야 합니다.
마지막으로 여러 위치에서 플러그인을 언급해야 합니다.
package.json 의 "devDependency" 필드에 eslint-plugin-foobar를 추가합니다..eslintrc.base.js 및 eslint.base.config.js 에서 사용되는지 확인하세요.README.md 의 지원되는 플러그인 목록에 추가하세요. 완료되면 npm test 실행하여 문제가 없는지 확인하세요. 여러 가지 다른 npm 스크립트를 실행합니다.
"test:prettier" 는 Prettier가 모든 파일에서 실행되었는지 확인합니다."test:eslint" eslint-config-prettier의 제외가 사용될 때 test-lint/ 의 파일이 ESLint를 통과하는지 확인합니다. 또한 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에 대한 온전성 검사입니다. MIT.
