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" ,
} ,
} ,
] ;ด้วยรูปแบบ “flat config” ของ ESLint ใหม่ คุณสามารถควบคุมสิ่งที่จะแทนที่สิ่งที่ตัวคุณเองได้ วิธีหนึ่งในการแก้ไขข้อขัดแย้งข้างต้นคือการเรียงลำดับวัตถุ config ใหม่เพื่อให้ 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 จะเก็บบรรทัดว่างไว้ โดยมีข้อยกเว้น 2 ประการ:
ตามค่าเริ่มต้น 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 ตราบใดที่ตัวเลือก 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 เช่นกัน)
กฎนี้ต้องการตัวเลือกบางอย่างและตัวเลือกที่สวยกว่าบางอย่าง
โดยปกติแล้วคุณไม่จำเป็นต้องใช้กฎนี้เลย แต่มีสองกรณีที่อาจมีประโยชน์:
หากคุณต้องการให้สตริงทั้งหมดใช้ backticks (ไม่ต้องใส่เครื่องหมายคำพูด) ให้เปิดใช้งานตัวเลือก "backtick"
ตัวอย่างการกำหนดค่า ESLint:
{
"rules" : {
"quotes" : [ " error " , " backtick " ]
}
}ในตัวอย่างต่อไปนี้ รายการอาร์เรย์แรกสามารถเขียนด้วยเครื่องหมายคำพูดแทน backticks
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 เพื่อไม่อนุญาตให้ backticks ที่ไม่จำเป็น ESLint:
{
"rules" : {
"quotes" : [
" error " ,
" double " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}สวยกว่า (นี่คือค่าเริ่มต้น ดังนั้นจึงไม่จำเป็นต้องเพิ่ม):
{
"singleQuote" : false
}ESLint:
{
"rules" : {
"quotes" : [
" error " ,
" single " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}สวยกว่า:
{
"singleQuote" : true
}กฎนี้สามารถใช้ได้กับตัวเลือกบางอย่าง
กฎนี้จะแก้ไขการเยื้องของเทมเพลตสตริงหลายบรรทัดโดยอัตโนมัติ เพื่อให้เทมเพลตสอดคล้องกับโค้ดที่พบ รายการไวท์ลิสต์ที่กำหนดค่าได้นั้นถูกใช้เพื่อให้แน่ใจว่าไม่มีการแก้ไขสตริงที่ไวต่อช่องว่าง
ข้อเสนอที่สวยกว่าด้วย:
การใช้แท็ก ฟังก์ชัน และความคิดเห็นต่างๆ
unicorn/template-indent ตามรูปแบบเริ่มต้นของเทมเพลตที่ติดแท็กเดียวกันบางส่วน ซึ่งอาจทำให้เกิดความขัดแย้งได้ ตัวอย่างเช่น กฎและ Prettier ไม่เห็นด้วยกับการเยื้องใน ternaries:
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 ที่เป็นโมฆะ ที่รู้จัก Prettier จะใช้สไตล์ปิดตัวเองเสมอ ตัวอย่างเช่น <img> จะกลายเป็น <img />
หากคุณชอบกฎนี้ ก็สามารถใช้ได้ดีกับ Prettier ตราบใดที่คุณตั้งค่า html.void เป็น "any"
ตัวอย่างการกำหนดค่า ESLint:
{
"rules" : {
"vue/html-self-closing" : [
" error " ,
{
"html" : {
"void" : " any "
}
}
]
}
}กฎเหล่านี้ไม่ขัดแย้งกับ Prettier แต่มี gotchas บางอย่างเมื่อใช้กับ Prettier
กฎนี้ห้ามใช้ตัวดำเนินการเครื่องหมายจุลภาคที่ทำให้สับสนของ JavaScript (นิพจน์ลำดับ) โค้ดชิ้นนี้ไม่ได้ทำในสิ่งที่ดูเหมือน:
matrix [ 4 , 7 ] ;Prettier เพิ่มวงเล็บด้านบนเพื่อให้ชัดเจนว่ามีการใช้นิพจน์ลำดับ:
matrix [ ( 4 , 7 ) ] ; อย่างไรก็ตาม กฎ no-sequences จะอนุญาตให้ใช้ตัวดำเนินการลูกน้ำได้ หากลำดับนิพจน์ถูกล้อมไว้อย่างชัดเจนในวงเล็บ เนื่องจาก Prettier จะล้อมไว้ในวงเล็บโดยอัตโนมัติ คุณอาจไม่เห็นคำเตือนใดๆ จาก ESLint เกี่ยวกับตัวดำเนินการลูกน้ำ
การลงท้ายด้วยนิพจน์ลำดับโดยไม่ตั้งใจสามารถเกิดขึ้นได้ง่ายในขณะที่ปรับโครงสร้างใหม่ หากคุณต้องการให้ ESLint จับข้อผิดพลาดดังกล่าว ขอแนะนำให้ห้ามไม่ให้นิพจน์ลำดับทั้งหมดโดยใช้ไวยากรณ์ที่ไม่จำกัด (ดังที่กล่าวไว้ในเอกสาร no-sequences ):
{
"rules" : {
"no-restricted-syntax" : [ " error " , " SequenceExpression " ]
}
} หากคุณยังจำเป็นต้องใช้ตัวดำเนินการลูกน้ำสำหรับ Edge Case บางตัว คุณสามารถใส่ความคิดเห็น // 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.jsREADME.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 เอ็มไอที.
