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" إلى المصفوفة "الممتدة" في ملف .eslintrc.* الخاص بك. تأكد من وضعه أخيرًا، حتى تحصل على فرصة لتجاوز التكوينات الأخرى.
{
"extends" : [
" some-other-config-you-use " ,
" prettier "
]
}eslint.config.js (flat config): قم باستيراد eslint-config-prettier، ووضعه في مصفوفة التكوين – بعد التكوينات الأخرى التي تريد تجاوزها.
import someConfig from "some-other-config-you-use" ;
import eslintConfigPrettier from "eslint-config-prettier" ;
export default [
someConfig ,
eslintConfigPrettier ,
] ; أخيرًا، قم بتشغيل أداة مساعد CLI للعثور على المشكلات في أقسام "rules" في ملف التكوين الخاص بك.
باستخدام eslint-البرنامج المساعد-أجمل؟ تحقق من التكوين الموصى به لـ 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 نفسها، يمكنك التحكم في أداة المساعدة eslint-config-prettier CLI باستخدام متغير البيئة 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 and 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 أيضًا.)
تتطلب هذه القاعدة خيارات معينة وخيارات أجمل معينة.
عادة، لا تحتاج إلى هذه القاعدة على الإطلاق. ولكن هناك حالتين يمكن أن يكون مفيدًا فيهما:
إذا كنت تريد أن تستخدم جميع السلاسل علامات التحديد الخلفية (عدم الاقتباس مطلقًا)، فقم بتمكين خيار "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's SingleQuote."avoidEscape": true لاتباع قواعد تنسيق سلسلة Prettier."allowTemplateLiterals": false لعدم السماح بالنقرات الخلفية غير الضرورية. إي إس لينت:
{
"rules" : {
"quotes" : [
" error " ,
" double " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}أجمل (هذا هو الإعداد الافتراضي، لذا فإن إضافة هذا غير مطلوب):
{
"singleQuote" : false
}إي إس لينت:
{
"rules" : {
"quotes" : [
" error " ,
" single " ,
{ "avoidEscape" : true , "allowTemplateLiterals" : false }
]
}
}أجمل:
{
"singleQuote" : true
}يمكن استخدام هذه القاعدة مع خيارات معينة.
ستعمل هذه القاعدة تلقائيًا على إصلاح المسافة البادئة لقوالب السلسلة متعددة الأسطر، لإبقائها متوافقة مع التعليمات البرمجية الموجودة فيها. ويتم استخدام قائمة بيضاء قابلة للتكوين لضمان عدم تحرير أي سلاسل حساسة للمسافات البيضاء.
صفقات أجمل مع:
استخدام العلامات والوظائف والتعليقات المختلفة.
يقوم 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" ، فلن تتمكن أداة مساعد سطر الأوامر من اكتشاف ما إذا كانت محدداتك قد تسبب تعارضات.
تتطلب هذه القاعدة خيارات معينة.
تفرض هذه القاعدة ما إذا كانت العناصر يجب أن تكون ذاتية الإغلاق أم لا.
يحافظ 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، ولكنها تحتوي على بعض الأخطاء عند استخدامها مع 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. معهد ماساتشوستس للتكنولوجيا.
