الصفحة الرئيسية>المتعلقة بالبرمجة>شفرة المصدر الأخرى
تنزيل

؟ نظموا الوبر

قم بتشغيل linters ضد ملفات git المرحلية ولا تسمح بذلك؟ تنزلق إلى قاعدة التعليمات البرمجية الخاصة بك! 

npm install --save-dev lint-staged # requires further setup 
 $ git commit

✔ Preparing lint-staged...
❯ Running tasks for staged files...
  ❯ packages/frontend/.lintstagedrc.json — 1 file
    ↓ *.js — no files [SKIPPED]
    ❯ *.{json,md} — 1 file
      ⠹ prettier --write
  ↓ packages/backend/.lintstagedrc.json — 2 files
    ❯ *.js — 2 files
      ⠼ eslint --fix
    ↓ *.{json,md} — no files [SKIPPED]
◼ Applying modifications from tasks...
◼ Cleaning up temporary files...
شاهد فيديو asciinema

لماذا

يكون الفحص أكثر منطقية عند تشغيله قبل تنفيذ التعليمات البرمجية الخاصة بك. من خلال القيام بذلك، يمكنك التأكد من عدم وجود أخطاء في المستودع وفرض نمط التعليمات البرمجية. لكن تشغيل عملية فحص الوبر على مشروع بأكمله يكون بطيئًا، ويمكن أن تكون نتائج الفحص غير ذات صلة. في النهاية، أنت فقط تريد فحص الملفات التي سيتم الالتزام بها.

يحتوي هذا المشروع على برنامج نصي يقوم بتشغيل مهام الصدفة العشوائية مع قائمة من الملفات المرحلية كوسيطة، والتي تمت تصفيتها بواسطة نمط الكرة الأرضية المحدد.

منشورات ومحادثات المدونة ذات الصلة

  • منشور تمهيدي متوسط ​​- أندريه أوكونيتشنيكوف، 2016
  • تشغيل اختبارات Jest قبل كل التزام بـ Git - بن ماكورميك، 2017
  • عرض AgentConf - أندريه أوكونيتشنيكوف، 2018
  • مقابلة SurviveJS مع Juho Vepsäläinen وAndrey Okonetchnikov، 2018
  • يمكنك تحسين CSharp الخاص بك باستخدام dotnet-format ونظام lint-staged

إذا كنت قد كتبت واحدًا، فيرجى إرسال تقرير العلاقات العامة مع الرابط الخاص به!

التثبيت والإعداد

لتثبيت lint-staged بالطريقة الموصى بها، تحتاج إلى:

  1. تثبيت الوبر نظموا أنفسهم:
    • npm install --save-dev lint-staged
  2. قم بإعداد خطاف git pre-commit لتشغيله على مراحل
    • يعد Husky خيارًا شائعًا لتكوين خطافات git
    • اقرأ المزيد عن خطافات git هنا
  3. قم بتثبيت بعض الفلاتر، مثل ESLint أو Prettier
  4. قم بتكوين نظام الوبر المرحلي لتشغيل الوبر والمهام الأخرى:
    • على سبيل المثال: { "*.js": "eslint" } لتشغيل ESLint لجميع ملفات JS المرحلية
    • راجع التكوين لمزيد من المعلومات

لا تنس إجراء تغييرات على package.json و .husky لمشاركة هذا الإعداد مع فريقك!

الآن قم بتغيير بعض الملفات، git add أو git add --patch بعضها إلى التزامك، وحاول git commit بها.

راجع الأمثلة والتكوين لمزيد من المعلومات.

سجل التغيير

انظر الإصدارات.

الهجرة

v15

  • نظرًا لأن v15.0.0 نظام lint-staging لم يعد يدعم Node.js 16. يرجى ترقية إصدار Node.js الخاص بك إلى 18.12.0 على الأقل.

v14

  • نظرًا لأن v14.0.0 نظام lint-staging لم يعد يدعم Node.js 14. يرجى ترقية إصدار Node.js الخاص بك إلى 16.14.0 على الأقل.

v13

  • نظرًا لأن v13.0.0 من نظام lint-staged لم يعد يدعم Node.js 12. يرجى ترقية إصدار Node.js الخاص بك إلى 14.13.1 على الأقل، أو 16.0.0 وما بعده.
  • تم إصدار الإصدار v13.3.0 بشكل غير صحيح بما في ذلك رمز الإصدار v14.0.0 . وهذا يعني أن التغييرات العاجلة v14 مضمنة أيضًا في v13.3.0 ، الإصدار الأخير من الإصدار v13

الإصدار 12

  • نظرًا لأن v12.0.0 lint-staged هو وحدة ESM خالصة، لذا تأكد من أن إصدار Node.js الخاص بك هو 12.20.0 أو 14.13.1 أو 16.0.0 على الأقل. اقرأ المزيد عن وحدات ESM من موقع توثيق Node.js الرسمي هنا.

v10

  • بدءًا من v10.0.0 فصاعدًا، ستتم تلقائيًا إضافة أي تعديلات جديدة على الملفات التي تم تنظيمها في الأصل إلى الالتزام. إذا كانت مهمتك تحتوي سابقًا على خطوة git add ، فيرجى إزالة هذه الخطوة. يضمن السلوك التلقائي وجود حالات سباق أقل، نظرًا لأن محاولة تشغيل عمليات git متعددة في نفس الوقت عادةً ما تؤدي إلى حدوث خطأ.
  • بدءًا من v10.0.0 فصاعدًا، يستخدم نظام lint-staging مخابئ git لتحسين السرعة وتوفير النسخ الاحتياطية أثناء التشغيل. نظرًا لأن عمليات تخزين git تتطلب التزامًا مبدئيًا على الأقل، فلا يجب تشغيلها على مراحل في مستودع فارغ.
  • بدءًا من v10.0.0 وما بعده، يتطلب تنظيم الوبر إصدار Node.js 10.13.0 أو إصدار أحدث.
  • بدءًا من v10.0.0 فصاعدًا، سيؤدي نظام lint-staged إلى إلغاء الالتزام إذا تراجعت مهام linter عن جميع التغييرات المرحلية. للسماح بإنشاء التزام فارغ، يرجى استخدام الخيار --allow-empty .

أعلام سطر الأوامر 

 ❯ npx lint-staged --help
Usage: lint-staged [options]

Options:
  -V, --version                      output the version number
  --allow-empty                      allow empty commits when tasks revert all staged changes (default: false)
  -p, --concurrent <number|boolean>  the number of tasks to run concurrently, or false for serial (default: true)
  -c, --config [path]                path to configuration file, or - to read from stdin
  --cwd [path]                       run all tasks in specific directory, instead of the current
  -d, --debug                        print additional debug information (default: false)
  --diff [string]                    override the default "--staged" flag of "git diff" to get list of files. Implies
                                     "--no-stash".
  --diff-filter [string]             override the default "--diff-filter=ACMR" flag of "git diff" to get list of files
  --max-arg-length [number]          maximum length of the command-line argument string (default: 0)
  --no-stash                         disable the backup stash, and do not revert in case of errors. Implies
                                     "--no-hide-partially-staged".
  --no-hide-partially-staged         disable hiding unstaged changes from partially staged files
  -q, --quiet                        disable lint-staged’s own console output (default: false)
  -r, --relative                     pass relative filepaths to tasks (default: false)
  -x, --shell [path]                 skip parsing of tasks for better shell support (default: false)
  -v, --verbose                      show task output even when tasks succeed; by default only failed output is shown
                                     (default: false)
  -h, --help                         display help for command
  • --allow-empty : بشكل افتراضي، عندما تتراجع مهام linter عن جميع التغييرات المرحلية، سيتم الخروج من lint-staged مع وجود خطأ وإجهاض الالتزام. استخدم هذه العلامة للسماح بإنشاء التزامات git الفارغة.
  • --concurrent [number|boolean] : يتحكم في تزامن المهام التي يتم تشغيلها بواسطة نظام lint-staging. ملاحظة : لا يؤثر هذا على تزامن المهام الفرعية (سيتم تشغيلها دائمًا بالتسلسل). القيم المحتملة هي:
    • false : تشغيل كافة المهام بشكل تسلسلي
    • true (افتراضي): التزامن اللانهائي . يقوم بتشغيل أكبر عدد ممكن من المهام بالتوازي.
    • {number} : تشغيل العدد المحدد من المهام بالتوازي، حيث 1 يعادل false .
  • --config [path] : حدد المسار يدويًا لملف التكوين أو اسم حزمة npm. ملاحظة: عند استخدامه، لن يقوم نظام lint-staged بالبحث عن ملف التكوين وسيطبع خطأ إذا تعذر العثور على الملف المحدد. إذا تم توفير '-' كاسم ملف، فستتم قراءة التكوين من stdin، مما يسمح بتوصيل الأنابيب في التكوين مثل cat my-config.json | npx lint-staged --config - .
  • --cwd [path] : يتم تشغيل المهام افتراضيًا في دليل العمل الحالي. استخدم --cwd some/directory لتجاوز هذا. يمكن أن يكون المسار مطلقًا أو متعلقًا بدليل العمل الحالي.
  • --debug : تشغيل في وضع التصحيح. عند الضبط يقوم بما يلي:
    • يستخدم التصحيح داخليًا لتسجيل معلومات إضافية حول الملفات المرحلية، والأوامر التي يتم تنفيذها، وموقع الثنائيات، وما إلى ذلك. يمكن أيضًا تمكين سجلات التصحيح، التي يتم تمكينها تلقائيًا عن طريق تمرير العلامة، عن طريق تعيين متغير البيئة $DEBUG إلى lint-staged* .
    • يستخدم العارض verbose لـ listr2 ؛ يؤدي هذا إلى إخراج تسلسلي غير ملون إلى الجهاز، بدلاً من الإخراج الافتراضي (المجمل والديناميكي). (يمكن أيضًا تنشيط العارض verbose عن طريق تعيين TERM=dumb أو NODE_ENV=test )
  • --diff : بشكل افتراضي، تتم تصفية الفلاتر مقابل جميع الملفات التي تم تنظيمها في git، والتي تم إنشاؤها من git diff --staged . يتيح لك هذا الخيار تجاوز العلامة --staged بمراجعات عشوائية. على سبيل المثال، للحصول على قائمة بالملفات التي تم تغييرها بين فرعين، استخدم --diff="branch1...branch2" . يمكنك أيضًا قراءة المزيد من حول git diff و gitrevisions. يتضمن هذا الخيار أيضًا --no-stash .
  • --diff-filter : بشكل افتراضي، يتم تضمين الملفات التي تمت إضافتها أو نسخها أو تعديلها أو إعادة تسميتها فقط. استخدم هذه العلامة لتجاوز قيمة ACMR الافتراضية بشيء آخر: تمت الإضافة ( A ) والنسخ ( C ) والحذف ( D ) والتعديل ( M ) وإعادة التسمية ( R ) والنوع الذي تم تغييره ( T ) والغير مدمج ( U ) وغير معروف ( X )، أو الاقتران مكسور ( B ). راجع أيضًا مستندات git diff لـ --diff-filter.
  • --max-arg-length : يتم تقسيم الأوامر الطويلة (الكثير من الملفات) تلقائيًا إلى أجزاء متعددة عندما تكتشف أن الغلاف الحالي لا يمكنه التعامل معها. استخدم هذه العلامة لتجاوز الحد الأقصى لطول سلسلة الأمر التي تم إنشاؤها.
  • --no-stash : افتراضيًا، سيتم إنشاء نسخة احتياطية قبل تشغيل المهام، وسيتم التراجع عن جميع تعديلات المهام في حالة حدوث خطأ. سيؤدي هذا الخيار إلى تعطيل إنشاء المخبأ، وبدلاً من ذلك يترك جميع التعديلات في الفهرس عند إلغاء الالتزام. يمكن إعادة تمكينه باستخدام --stash . يتضمن هذا الخيار أيضًا --no-hide-partially-staged .
  • --no-hide-partially-staged : افتراضيًا، سيتم إخفاء التغييرات غير المرحلية من الملفات المرحلية جزئيًا. سيؤدي هذا الخيار إلى تعطيل هذا السلوك ويتضمن كافة التغييرات غير المرحلية في الملفات المرحلية جزئيًا. يمكن إعادة تمكينه باستخدام --hide-partially-staged
  • --quiet : قمع جميع مخرجات CLI، باستثناء المهام.
  • --relative : تمرير مسارات الملفات المتعلقة بـ process.cwd() (حيث يتم تشغيل lint-staged ) إلى المهام. الافتراضي false .
  • --shell : افتراضيًا، سيتم تحليل أوامر linter من حيث السرعة والأمان. وهذا له أثر جانبي يتمثل في أن نصوص الصدفة العادية قد لا تعمل كما هو متوقع. يمكنك تخطي تحليل الأوامر باستخدام هذا الخيار. لاستخدام غلاف محدد، استخدم مسارًا مثل --shell "/bin/bash" .
  • --verbose : إظهار مخرجات المهمة حتى عندما تنجح المهام. بشكل افتراضي، يتم عرض المخرجات الفاشلة فقط.

إعدادات

يمكن تكوين نظام تنظيم الوبر بعدة طرق:

  • كائن lint-staged في package.json أو package.yaml
  • ملف .lintstagedrc بتنسيق JSON أو YML، أو يمكنك أن تكون صريحًا بامتداد الملف:
    • .lintstagedrc.json
    • .lintstagedrc.yaml
    • .lintstagedrc.yml
  • ملف .lintstagedrc.mjs أو lint-staged.config.mjs بتنسيق ESM
    • يجب أن تكون قيمة التصدير الافتراضية عبارة عن تكوين: export default { ... }
  • .lintstagedrc.cjs أو ملف lint-staged.config.cjs بتنسيق CommonJS
    • يجب أن تكون قيمة الصادرات عبارة عن تكوين: module.exports = { ... }
  • lint-staged.config.js أو .lintstagedrc.js بتنسيق ESM أو CommonJS، اعتمادًا على ما إذا كانت حزمة json الخاصة بمشروعك تحتوي على خيار "type": "module" أم لا.
  • قم بتمرير ملف التكوين باستخدام علامة --config أو -c

يجب أن يكون التكوين عبارة عن كائن حيث تكون كل قيمة بمثابة أمر ليتم تشغيله ويكون مفتاحها عبارة عن نمط عالمي لاستخدامه في هذا الأمر. تستخدم هذه الحزمة micromatch لأنماط الكرة الأرضية. يمكن لملفات JavaScript أيضًا تصدير التكوين المتقدم كوظيفة. راجع استخدام ملفات تكوين JS لمزيد من المعلومات.

يمكنك أيضًا وضع ملفات تكوين متعددة في أدلة مختلفة داخل المشروع. بالنسبة لملف مرحلي محدد، سيتم دائمًا استخدام أقرب ملف تكوين. راجع "كيفية استخدام lint-staged في monorepo متعدد العبوات؟" لمزيد من المعلومات ومثال.

مثال package.json : 

{
  "lint-staged" : {
    "*" : " your-cmd "
  }
}

مثال .lintstagedrc 

{
  "*" : " your-cmd "
}

سيقوم هذا التكوين بتنفيذ your-cmd مع قائمة الملفات المرحلية الحالية التي تم تمريرها كوسائط.

لذا، مع الأخذ في الاعتبار أنك قمت git add file1.ext file2.ext ، فسوف يقوم lint-staged بتشغيل الأمر التالي:

your-cmd file1.ext file2.ext

تزامن المهمة

افتراضيًا، سوف يقوم نظام lint-staging بتشغيل المهام التي تم تكوينها بشكل متزامن. هذا يعني أنه بالنسبة لكل كرة، سيتم تشغيل كافة الأوامر في نفس الوقت. باستخدام التكوين التالي، سيتم تشغيل كل من eslint و prettier في نفس الوقت: 

{
  "*.ts" : " eslint " ,
  "*.md" : " prettier --list-different "
}

هذه ليست مشكلة عادةً نظرًا لأن الكرات لا تتداخل، ولا تجري الأوامر تغييرات على الملفات، ولكنها تبلغ فقط عن الأخطاء المحتملة (إجهاض التزام git). إذا كنت تريد تشغيل أوامر متعددة لنفس مجموعة الملفات، فيمكنك استخدام بناء جملة المصفوفة للتأكد من تشغيل الأوامر بالترتيب. في المثال التالي، سيتم تشغيل prettier لكلا الكرتين، وبالإضافة إلى ذلك سيتم تشغيل eslint لملفات *.ts بعده . لا تزال مجموعتا الأوامر (لكل كرة أرضية) تبدأان في نفس الوقت (لكن لا تتداخلان). 

{
  "*.ts" : [ " prettier --list-different " , " eslint " ],
  "*.md" : " prettier --list-different "
}

انتبه أكثر عندما تتداخل الكرات المكونة، وتقوم المهام بإجراء تعديلات على الملفات. على سبيل المثال، في هذا التكوين قد يحاول eslint و prettier إجراء تغييرات على نفس الملف *.ts في نفس الوقت، مما يتسبب في حدوث حالة سباق : 

{
  "*" : " prettier --write " ,
  "*.ts" : " eslint --fix "
}

يمكنك حلها باستخدام نمط النفي وبناء جملة المصفوفة: 

{
  "!(*.ts)" : " prettier --write " ,
  "*.ts" : [ " eslint --fix " , " prettier --write " ]
}

مثال آخر تقوم فيه المهام بإجراء تعديلات على الملفات والكرات الأرضية التي تتطابق مع ملفات متعددة ولكنها لا تتداخل: 

{
  "*.css" : [ " stylelint --fix " , " prettier --write " ],
  "*.{js,jsx}" : [ " eslint --fix " , " prettier --write " ],
  "!(*.css|*.js|*.jsx)" : [ " prettier --write " ]
}

أو، إذا لزم الأمر، يمكنك تحديد التزامن باستخدام --concurrent <number> أو تعطيله بالكامل باستخدام --concurrent false .

تصفية الملفات

تعمل أوامر Linter على مجموعة فرعية من جميع الملفات المرحلية، المحددة بنمط الكرة الأرضية . يستخدم نظام lint-staging micromatch لمطابقة الملفات بالقواعد التالية:

  • إذا كان نمط الكرة الأرضية لا يحتوي على خطوط مائلة ( / )، فسيتم تمكين خيار matchBase الخاص بـ micromatch، لذا فإن الكرة الأرضية تطابق الاسم الأساسي للملف بغض النظر عن الدليل:
    • سيطابق "*.js" جميع ملفات JS، مثل /test.js و /foo/bar/test.js
    • سوف يطابق "!(*test).js" جميع ملفات JS، باستثناء تلك التي تنتهي بـ test.js ، لذا foo.js ولكن ليس foo.test.js
    • "!(*.css|*.js)" سيطابق جميع الملفات باستثناء ملفات CSS وJS
  • إذا كان النمط الشامل يحتوي على شرطة مائلة ( / )، فسوف يتطابق مع المسارات أيضًا:
    • سيطابق "./*.js" جميع ملفات JS في جذر git repo، لذا /test.js ولكن ليس /foo/bar/test.js
    • سيطابق "foo/**/*.js" جميع ملفات JS الموجودة داخل الدليل /foo ، لذا /foo/bar/test.js ولكن ليس /test.js

عند المطابقة، سيقوم نظام lint-staged بما يلي

  • قم بحل جذر git تلقائيًا، دون الحاجة إلى تكوين.
  • اختر الملفات المرحلية الموجودة داخل دليل المشروع.
  • قم بتصفيتها باستخدام أنماط الكرة الأرضية المحددة.
  • قم بتمرير المسارات المطلقة إلى الـ linters كوسيطات.

ملاحظة: سوف يقوم lint-staged بتمرير المسارات المطلقة إلى وحدات القياس لتجنب أي ارتباك في حالة تنفيذها في دليل عمل مختلف (أي عندما لا يكون دليل .git هو نفس دليل package.json الخاص بك).

راجع أيضًا كيفية استخدام lint-staged في monorepo متعدد العبوات؟

تجاهل الملفات

يتمثل مفهوم lint-staged في تشغيل مهام linter التي تم تكوينها (أو مهام أخرى) على الملفات التي تم تنظيمها في git. سوف يقوم lint-staged دائمًا بتمرير قائمة بجميع الملفات المرحلية إلى المهمة، ويجب تكوين تجاهل أي ملفات في المهمة نفسها.

فكر في مشروع يستخدم prettier للحفاظ على تنسيق التعليمات البرمجية متسقًا عبر جميع الملفات. يقوم المشروع أيضًا بتخزين مكتبات البائعين الخارجية المصغرة في دليل vendor/ . للحفاظ على prettier من إلقاء الأخطاء على هذه الملفات، يجب إضافة دليل البائع إلى تكوين تجاهل بريتيير، الملف .prettierignore . تشغيل npx prettier . سوف يتجاهل دليل البائع بأكمله، دون حدوث أي أخطاء. عند إضافة lint-staged إلى المشروع وتكوينه لتشغيل أجمل، سيتم تجاهل جميع الملفات المعدلة والمقسمة إلى مراحل في دليل البائع بواسطة Pretter، على الرغم من أنه يستقبلها كمدخلات.

في السيناريوهات المتقدمة، حيث يكون من المستحيل تكوين مهمة linter نفسها لتجاهل الملفات، ولكن يجب أن يتم تجاهل بعض الملفات المرحلية بواسطة lint-staged ، فمن الممكن تصفية مسارات الملفات قبل تمريرها إلى المهام باستخدام بناء جملة الوظيفة. انظر المثال: تجاهل الملفات من المباراة.

ما هي الأوامر المدعومة؟

يتم دعم أي ملفات تنفيذية تم تثبيتها محليًا أو عالميًا عبر npm بالإضافة إلى أي ملف قابل للتنفيذ من $PATH.

لا يُنصح باستخدام البرامج النصية المثبتة عالميًا، نظرًا لأن نظام الوبر المرحلي قد لا يعمل مع شخص لم يتم تثبيته.

يستخدم lint-staged execa لتحديد البرامج النصية المثبتة محليًا. لذلك في .lintstagedrc الخاص بك يمكنك الكتابة: 

{
  "*.js" : " eslint --fix "
}

سيؤدي هذا إلى تشغيل eslint --fix file-1.js file-2.js على مراحل ، عندما يكون لديك ملفات مرحلية file-1.js و file-2.js و README.md .

قم بتمرير الوسيطات إلى أوامرك مفصولة بمسافة كما تفعل في الصدفة. انظر الأمثلة أدناه.

تشغيل أوامر متعددة بالتسلسل

يمكنك تشغيل أوامر متعددة بالتسلسل على كل كرة أرضية. للقيام بذلك، قم بتمرير مجموعة من الأوامر بدلاً من أمر واحد. يعد هذا مفيدًا لتشغيل أدوات التنسيق التلقائي مثل eslint --fix أو stylefmt ولكن يمكن استخدامه لأي تسلسلات عشوائية.

على سبيل المثال: 

{
  "*.js" : [ " eslint " , " prettier --write " ]
}

سيتم تنفيذ eslint وإذا تم الخروج برمز 0 ، فسيتم تنفيذ prettier --write على جميع ملفات *.js المرحلية.

سيؤدي هذا إلى تشغيل eslint file-1.js file-2.js على مراحل ، عندما يكون لديك ملفات مرحلية file-1.js و file-2.js و README.md ، وإذا نجحت، فإن prettier --write file-1.js file-2.js .

باستخدام ملفات التكوين JS

تعد كتابة ملف التكوين في JavaScript أقوى طريقة لتكوين نظام lint-staged ( lint-staged.config.js أو مشابه أو يتم تمريره عبر --config ). من ملف التكوين، يمكنك تصدير إما وظيفة واحدة أو كائن.

إذا كانت قيمة exports دالة، فسوف تتلقى مصفوفة من جميع أسماء الملفات المرحلية. يمكنك بعد ذلك إنشاء المطابقات الخاصة بك للملفات وإرجاع سلسلة أوامر أو مجموعة من سلاسل الأوامر. تعتبر هذه السلاسل كاملة ويجب أن تتضمن وسيطات اسم الملف، إذا لزم الأمر.

إذا كانت قيمة exports عبارة عن كائن، فيجب أن تكون مفاتيحه متطابقة بشكل عام (كما هو الحال في تنسيق التكوين العادي غير js). يمكن أن تكون القيم كما هي في التكوين العادي أو الوظائف الفردية كما هو موضح أعلاه. بدلاً من تلقي جميع الملفات المطابقة، ستتلقى الوظائف الموجودة في الكائن المصدر فقط الملفات المرحلية المطابقة للمفتاح الشامل المقابل.

للتلخيص، بشكل افتراضي، يضيف نظام lint-staged تلقائيًا قائمة الملفات المرحلية المتطابقة إلى أمرك، ولكن عند إنشاء الأمر باستخدام وظائف JS، من المتوقع القيام بذلك يدويًا. على سبيل المثال: 

 export default {
  '*.js' : ( stagedFiles ) => [ `eslint .` , `prettier --write ${ stagedFiles . join ( ' ' ) } ` ] ,
}

سيؤدي هذا إلى تشغيل eslint لأول مرة على مراحل eslint . (يطابق جميع الملفات)، وإذا نجح، prettier --write file-1.js file-2.js ، عندما يكون لديك ملفات منظمة file-1.js و file-2.js و README.md .

توقيع الوظيفة

يمكن أن تكون الوظيفة أيضًا غير متزامنة: 

 ( filenames : string [ ] ) => string | string [ ] | Promise < string | string [ ] >

مثال: قم بتصدير دالة لإنشاء المطابقات الخاصة بك

انقر للتوسيع 
 // lint-staged.config.js
import micromatch from 'micromatch'

export default ( allStagedFiles ) => {
  const shFiles = micromatch ( allStagedFiles , [ '**/src/**/*.sh' ] )
  if ( shFiles . length ) {
    return `printf '%sn' "Script files aren't allowed in src directory" >&2`
  }
  const codeFiles = micromatch ( allStagedFiles , [ '**/*.js' , '**/*.ts' ] )
  const docFiles = micromatch ( allStagedFiles , [ '**/*.md' ] )
  return [ `eslint ${ codeFiles . join ( ' ' ) } ` , `mdl ${ docFiles . join ( ' ' ) } ` ]
}

مثال: لف أسماء الملفات بين علامات اقتباس مفردة وتشغيلها مرة واحدة لكل ملف

انقر للتوسيع 
 // .lintstagedrc.js
export default {
  '**/*.js?(x)' : ( filenames ) => filenames . map ( ( filename ) => `prettier --write ' ${ filename } '` ) ,
}

مثال: قم بتشغيل tsc عند إجراء تغييرات على ملفات TypeScript، لكن لا تمرر أي وسيطات لاسم الملف

انقر للتوسيع 
 // lint-staged.config.js
export default {
  '**/*.ts?(x)' : ( ) => 'tsc -p tsconfig.json --noEmit' ,
}

مثال: قم بتشغيل ESLint على الريبو بأكمله إذا كان هناك أكثر من 10 ملفات مرحلية

انقر للتوسيع 
 // .lintstagedrc.js
export default {
  '**/*.js?(x)' : ( filenames ) =>
    filenames . length > 10 ? 'eslint .' : `eslint ${ filenames . join ( ' ' ) } ` ,
}

مثال: استخدم الكرات الخاصة بك

انقر للتوسيع

من الأفضل استخدام التكوين القائم على الوظيفة (كما هو موضح أعلاه)، إذا كانت حالة الاستخدام الخاصة بك هي هذه. 

 // lint-staged.config.js
import micromatch from 'micromatch'

export default {
  '*' : ( allFiles ) => {
    const codeFiles = micromatch ( allFiles , [ '**/*.js' , '**/*.ts' ] )
    const docFiles = micromatch ( allFiles , [ '**/*.md' ] )
    return [ `eslint ${ codeFiles . join ( ' ' ) } ` , `mdl ${ docFiles . join ( ' ' ) } ` ]
  } ,
}

مثال: تجاهل الملفات من المباراة

انقر للتوسيع

إذا كنت تريد لسبب ما تجاهل الملفات من مطابقة الكرة الأرضية، فيمكنك استخدام micromatch.not() : 

 // lint-staged.config.js
import micromatch from 'micromatch'

export default {
  '*.js' : ( files ) => {
    // from `files` filter those _NOT_ matching `*test.js`
    const match = micromatch . not ( files , '*test.js' )
    return `eslint ${ match . join ( ' ' ) } `
  } ,
}

يرجى ملاحظة أنه في معظم الحالات، يمكن أن تحقق الكرات نفس التأثير. في المثال أعلاه، ستكون الكرة الأرضية المطابقة هي !(*test).js .

مثال: استخدم المسارات النسبية للأوامر

انقر للتوسيع 
 import path from 'path'

export default {
  '*.ts' : ( absolutePaths ) => {
    const cwd = process . cwd ( )
    const relativePaths = absolutePaths . map ( ( file ) => path . relative ( cwd , file ) )
    return `ng lint myProjectName --files ${ relativePaths . join ( ' ' ) } `
  } ,
}

إعادة صياغة الكود

يمكن لأدوات مثل Prettier أو ESLint/TSLint أو stylelint إعادة تنسيق التعليمات البرمجية الخاصة بك وفقًا للتكوين المناسب عن طريق تشغيل prettier --write / eslint --fix / tslint --fix / stylelint --fix . سيضيف نظام Lint-staged تلقائيًا أي تعديلات على الالتزام طالما لم تكن هناك أخطاء. 

{
  "*.js" : " prettier --write "
}

قبل الإصدار 10، كان يتعين على المهام تضمين git add يدويًا كخطوة أخيرة. تم دمج هذا السلوك في نظام lint-stage نفسه لمنع حدوث حالات تعارض مع قيام مهام متعددة بتحرير نفس الملفات. إذا اكتشف نظام lint-staged git add في تكوينات المهام، فسيظهر تحذيرًا في وحدة التحكم. الرجاء إزالة git add من التكوين الخاص بك بعد الترقية.

أمثلة

تفترض جميع الأمثلة أنك قمت بالفعل بإعداد نظام lint-staging في ملف package.json وhusky في ملف التكوين الخاص به. 

{
  "name" : " My project " ,
  "version" : " 0.1.0 " ,
  "scripts" : {
    "my-custom-script" : " linter --arg1 --arg2 "
  },
  "lint-staged" : {}
}

في .husky/pre-commit 

 # .husky/pre-commit

npx lint-staged

ملحوظة: لا نمرر المسار كحجة للعدائين. هذا أمر مهم لأن نظام lint-staging سيفعل ذلك نيابةً عنك.

ESLint مع المعلمات الافتراضية لـ *.js و *.jsx التي تعمل كخطاف ما قبل الالتزام

انقر للتوسيع 
{
  "*.{js,jsx}" : " eslint "
}

قم بإصلاح نمط الكود تلقائيًا باستخدام --fix وإضافته للالتزام

انقر للتوسيع 
{
  "*.js" : " eslint --fix "
}

سيؤدي هذا إلى تشغيل eslint --fix وإضافة التغييرات تلقائيًا إلى الالتزام.

إعادة استخدام البرنامج النصي npm

انقر للتوسيع

إذا كنت ترغب في إعادة استخدام البرنامج النصي npm المحدد في package.json الخاص بك: 

{
  "*.js" : " npm run my-custom-script -- "
}

ما يلي يعادل: 

{
  "*.js" : " linter --arg1 --arg2 "
}

استخدم متغيرات البيئة مع أوامر الفحص

انقر للتوسيع

لا تدعم أوامر الفحص اصطلاح Shell الخاص بتوسيع متغيرات البيئة. لتمكين الاتفاقية بنفسك، استخدم أداة مثل cross-env .

على سبيل المثال، هنا يتم تشغيل jest على جميع ملفات .js مع تعيين المتغير NODE_ENV على "test" : 

{
  "*.js" : [ " cross-env NODE_ENV=test jest --bail --findRelatedTests " ]
}

إصلاح نمط الكود تلقائيًا مع prettier لأي تنسيق يدعمه Prettier

انقر للتوسيع 
{
  "*" : " prettier --ignore-unknown --write "
}

إصلاح نمط التعليمات البرمجية تلقائيًا بشكل prettier لـ JavaScript أو TypeScript أو Markdown أو HTML أو CSS

انقر للتوسيع 
{
  "*.{js,jsx,ts,tsx,md,html,css}" : " prettier --write "
}

Stylelint لـ CSS مع الإعدادات الافتراضية ولـ SCSS مع بناء جملة SCSS

انقر للتوسيع 
{
  "*.css" : " stylelint " ,
  "*.scss" : " stylelint --syntax=scss "
}

قم بتشغيل فرز PostCSS وStylint للتحقق

انقر للتوسيع 
{
  "*.scss" : [ " postcss --config path/to/your/config --replace " , " stylelint " ]
}

تصغير الصور

انقر للتوسيع 
{
  "*.{png,jpeg,jpg,gif,svg}" : " imagemin-lint-staged "
}
المزيد عن imagemin-lint-staged

imagemin-lint-staged هي أداة CLI مصممة للاستخدام المرحلي مع إعدادات افتراضية معقولة.

اطلع على المزيد في منشور المدونة هذا للتعرف على فوائد هذا النهج.

اكتب التحقق من ملفاتك المرحلية مع التدفق

انقر للتوسيع 
{
  "*.{js,jsx}" : " flow focus-check "
}

التكامل مع Next.js

انقر للتوسيع 
 // .lintstagedrc.js
// See https://nextjs.org/docs/basic-features/eslint#lint-staged for details

const path = require ( 'path' )

const buildEslintCommand = ( filenames ) =>
  `next lint --fix --file ${ filenames . map ( ( f ) => path . relative ( process . cwd ( ) , f ) ) . join ( ' --file ' ) } `

module . exports = {
  '*.{js,jsx,ts,tsx}' : [ buildEslintCommand ] ,
}

الأسئلة المتداولة

يبدو إخراج خطاف الالتزام غريبًا (لا توجد ألوان، أو خطوط مكررة، أو إخراج مطول على نظام التشغيل Windows، ...)

انقر للتوسيع

قدم Git 2.36.0 تغييرًا في الخطافات حيث لم يعد يتم تشغيلها في TTY الأصلي. تم إصلاح هذا في 2.37.0:

https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.37.0.txt

  • في Git 2.36 قمنا بتجديد الطريقة التي يتم بها استدعاء الخطافات. أحد التغييرات المرئية للمستخدم النهائي هو أن مخرجات الخطاف لم تعد متصلة مباشرة بالإخراج القياسي لـ "git" الذي يولد الخطاف، وهو ما تمت ملاحظته بعد الإصدار. يتم تصحيح هذا. (ادمج a082345372 ab/hooks-regression-fix لاحقًا للصيانة).

إذا لم يساعدك تحديث Git، فيمكنك محاولة إعادة توجيه الإخراج يدويًا في خطاف Git الخاص بك؛ على سبيل المثال: 

 # .husky/pre-commit

if sh -c " : >/dev/tty " > /dev/null 2> /dev/null ; then exec > /dev/tty 2>&1 ; fi

npx lint-staged

المصدر: typicode/husky#968 (تعليق)

هل يمكنني استخدام lint-staged عبر العقدة؟

انقر للتوسيع

نعم! 

 import lintStaged from 'lint-staged'

try {
  const success = await lintStaged ( )
  console . log ( success ? 'Linting was successful!' : 'Linting failed!' )
} catch ( e ) {
  // Failed to load configuration
  console . error ( e )
}

معلمات lintStaged تعادل نظيراتها من واجهة سطر الأوامر (CLI): 

 const success = await lintStaged ( {
  allowEmpty : false ,
  c
يوسع
معلومات إضافية
تطبيقات ذات صلة
نوصي لك
أخبار ذات صلة الكل