حتى وقت قريب ، في جميع مشاريع الواجهة ، استخدم مطورو Dodo Pizza Engineering tslint - وهي أداة مفيدة تخبرك عندما قمت بفك
الشفرة ، وجعلت معلومات غير دقيقة ، تساعد في الحفاظ على الشفرة بنفس الأسلوب وتصحيح العديد من التعليقات. ولكن بعد ذلك أخذ tslint وتوفي. تحت القصاصة ، سوف أخبرك لماذا حدث ذلك ، وكيفية إيقاف سكب الدموع على المتوفى والتحول إلى أداة eslint ، وأيضًا إظهار شيء حميم جدًا.
في الواقع ، بدأ كل شيء منذ وقت طويل: آخر إصدار من tslint kernel كان بالفعل في عام 2016. وهذه هي اللحظة التي حان الوقت للبدء في قول "الأخير" ، إذا كان شخص ما لا يزال يقول "الأخير" ، لأن هذا الإصدار كان الأخير حقًا. في 19 فبراير 2019 ، تم إصدار
وظيفة رسمية لإيقاف تطور tslint. في ذلك ، تنصح شركة التطوير (بالمناسبة ، ليست حتى شركة Microsoft) بشدة الجميع بالانتقال إلى eslint ، حيث أن جهودهم سوف تهدف الآن إلى تحسين دعم TypeScript في هذه اللغة.
لغة واحدة ، مجموعة واحدة ، مجتمع واحد
ترى Microsoft أن برنامج TypeScript هو اللغة الرئيسية لتطوير الويب ، والتي يجب أن تحل محل Java / ECMA Script. من الواضح أن مثل هذا الهدف الطموح يتضمن كومة أداة واحدة لتطوير الواجهة الأمامية بالكامل. هذا ينبغي أن يبسط إلى حد كبير هجرة مجتمع JS الكبير إلى TypeScript. بالإضافة إلى ضمان الثقة من Microsoft ، تمتلك eslint بنية أفضل من tslint. على سبيل المثال ، يمكنك توصيل المحللون ، وهناك المزيد من الخيارات للقواعد المتصلة.
مايكروسوفت لن تكون هي نفسها لو كانت مطلوبة فقط. مهما قلنا عن جودة برامجهم ، فإنهم يقومون بأدوات تطوير رائعة (وبالمناسبة ، أجهزة الإدخال). لذلك هذه المرة لم يأتوا خالي الوفاض ، لكنهم كتبوا
خطة للهجرة . وفقًا لهذه الخطة ، تم بالفعل إيقاف تطوير قواعد tslint في 1 أغسطس 2019 ، وسيتوقف تطوير tslint نفسه في 1 نوفمبر 2019. على الرغم من أن نكون صادقين ، فقد توقف التطوير منذ وقت طويل (انظر أعلاه للحصول على أحدث إصدار).
هنا يجب أن يصبح من الواضح للقارئ أن الوقت قد حان للتبديل إلى eslint ، لا يوجد خيار آخر. لتحلية حبوب منع الحمل ، تجدر الإشارة إلى أن:
- بينما تركز tslint على TypeScript مع التركيز بشكل أكبر على الاستخدام الصحيح للأنواع والتحقق من بناء الجملة ، فإن eslint يغطي كل ما يمكن أن يكون في المقدمة ، بما في ذلك بناء جملة React ؛
- يحتوي eslint على الكثير من القواعد المحددة مسبقًا ؛
- هناك قواعد (وإضافات) تتحقق من الكود على مستوى الكتلة (تكرار الكود ، التعقيد المتصور ، إلخ) ؛
- هناك مكونات إضافية لا تحقق الشفرة على الإطلاق ، ولكن ، على سبيل المثال ، التعبيرات العادية.
بشكل عام ، يبدو أن الانتقال إلى linter جديد ، وهو منتج رئيسي ، سوف يفتح أمامنا عالمًا كاملاً من الفرص غير المرئية سابقًا. حسنا ، دعونا نحاول!
أضف eslint إلى المشروع
سأتحدث عن ترحيل القواعد أدناه. في غضون ذلك ، قم بإعداد مشروع للعمل مع eslint.
إذا كان لديك بالفعل مشروع يحتوي على tslint ، فعليك أولاً إزالة جميع الحزم المتعلقة tslint منه: tslint نفسه ، tslint-react ، tslint-config-prettier ، إلخ.
أضف الآن حزم eslint إلى المشروع (اضبط كل شيء على أنه devDependencies):
- eslint نفسه ؛
- @ typescript-eslint / parser - محرك لتحليل TypeScript ؛
- @ typescript-eslint / eslint-plugin - مجموعات القواعد لـ TypeScript
الحد الأدنى من الإعداد Eslint
قم بإنشاء ملف التكوين .eslintrc.json. يدعم Eslint العديد من تنسيقات الملفات لتكوينه ، لكن JSON يبدو الأكثر ملاءمة. إليك ما يبدو عليه الخيار الأدنى للعمل:
{ // "env": { // "browser": true, // ES6 "es6": true, // ES2017 "es2017": true }, // "extends": [ // eslint "eslint:recommended", // "plugin:@typescript-eslint/eslint-recommended", // TypeScript "plugin:@typescript-eslint/recommended", // TS, "plugin:@typescript-eslint/recommended-requiring-type-checking" ], // "parser": "@typescript-eslint/parser", "parserOptions": { // TS "project": "tsconfig.json", "tsconfigRootDir": ".", }, // TypeScript "plugins": ["@typescript-eslint"], "rules": {} }
يخبر قسم
env eslint عن خيارات مشروعك. في المثال الخاص بي ، هذا مشروع للمتصفح (بمعنى أن الشفرة ستعمل في المتصفح). اكتب Node.JS - تعيين العقدة: صحيح. يشير الخياران التاليان إلى لهجة JS الجاري اختبارها. بشكل عام ، سوف نتحقق من رمز TypeScript ، ولكن إذا كان مشروعك يحتوي أيضًا على رمز JS ، فلا تنسى تشديده. لأنفسنا ، قررنا أن نضبط هذه المعلمات على نفس قيمة الهدف في tsconfig.json.
لا يوجد شيء مثير للجدل حول مجموعات قواعد eslint القياسية ، مثل الفاصلة المنقوطة المطلوبة في نهاية التعبيرات أو المسافات / علامات التبويب. جميع القواعد مفيدة بشكل فريد. يمكنك أن ترى ما هي القواعد ومع أي مستوى مدرج
هنا .
السطر التالي تحتاج إلى
تعطيل نصف القواعد. يعد ذلك ضروريًا لأنهم لا يعملون مع TypeScript وبدلاً من العمل بشكل طبيعي ، فإنهم سيلقون مجموعة من الأخطاء.
ثم يجب عليك توصيل القواعد الموصى بها من TypeScript في حقيبة منفصلة. هنا تحتاج إلى أن تضع في اعتبارك أن
قواعد بناء الجملة العامة (مثل حظر var) ستعمل بهذه الطريقة.
ولكن بالنسبة للقواعد التي
تستخدم أنواع TS (على سبيل المثال ، @ typescript-eslint / no-unstantion-type-assertion) ، فإن محرك TypeScript مطلوب. وسيحتاج المشغل إلى ملف tsconfig.json ، المسار الذي يجب تحديده.
في tsconfig.json ، نحن في Dodo Pizza Engineering عادة ما نحدد اختبارات الاستبعاد والقذف حتى لا يبنوا مع المشروع. ولكن لكي تعمل eslint ، يجب عليك تحديدها وإدراجها. بمعنى ، يجب تضمين كافة الملفات التي تحتاج إلى مسحها بشكل صريح في المشروع. بدون هذا ، ستؤدي eslint إلى أداء كل ملف تجده: "الملف غير موجود في المشروع ، لن أفعل شيئًا ، سألقي مجموعة من الأخطاء". يوجد خيار بدون تحديد ملفات المشروع بشكل صريح - قم بتعيين
createDefaultProgram: true . هذا ، في جوهره ، يعني: "كل ما تجده هو Parsi". لكن المطورين ينصحون بشدة بعدم القيام بذلك بسبب انخفاض كبير في الأداء.
إذا كنت تستخدم ForkTsCheckerWebpackPlugin لمعالجة ملفات TypeScript ،
tslint: true بـ
eslint: true في المعلمات الخاصة به (في webpack.config.ts).
كما أنه من الضروري إعداد عملية إطلاق linter من سطر الأوامر. قبل ذلك ، أضف هذه القيمة إلى قسم البرامج النصية في
package.json :
"eslint": "eslint --cache --ext .js,.jsx,.ts,.tsx src", "eslint:dump": "eslint --print-config ./.eslintrc.json",
يبدأ السطر الأول فقط في اختبار eslint دون إنشاء المشروع. يعرض الثاني إعدادات eslint الحالية ، والتي تتيح لك رؤية إعدادات معلمات القاعدة.
في هذا الإصدار ، ستعمل eslint بالفعل في المشروع وستلتقط حتى بعض المياه الضحلة: إعادة تعريف globals ، والمتغيرات غير المستخدمة ، إلخ.
إعداد رمز Visual Studio
بعد انتهائك من هذا الطريق ، يمكنك بالفعل بدء تشغيل linter من سطر الأوامر. كما سيتم إطلاقه ضمنيًا عند بناء المشروع. لكن في Visual Studio Code ، لن نرى تعليقات من linter. كيف ذلك؟
هناك مكون إضافي eslint للاستوديو (dbaeumer.vscode-eslint) ، يجب تثبيته. بعد ذلك ، لن ينجح شيء على أي حال ، لن يتم التأكيد على أي شيء وتصحيحه. لماذا؟ لأن المكون الإضافي يحتوي على تهيئة ، والتي تقول إن عليك العمل فقط في ملفات JavaScript.
لا يتم إعداد هذا الإعداد المتستر في واجهة المستخدم ، لذلك تحتاج إلى الدخول إلى ملف إعدادات الاستوديو وإضافة اللغات التي تحتاجها يدويًا إلى المعلمة eslint.validate. يمكن العثور على قائمة كاملة باللغات في أحشاء وثائق الاستوديو. إليك ما يبدو عليه هذا الإعداد معنا:
"eslint.validate": [ "javascript", "javascriptreact", "typescriptreact", "typescript", ],
بعد ذلك ، أعد تشغيل الاستوديو وسيبدأ كل شيء أخيرًا في العمل.
الآن يبقى لتكوين القواعد
تم إعداد المشروع. الآن حول القواعد ، لأنه في المثال أعلاه ، كانت قائمة القواعد فارغة.
يجب أن أقول أن tslint لم يمنعنا من العبث في التعليمات البرمجية الصحيحة رسميًا. على سبيل المثال ، ننسى الانتظار. يعرف Eslint كيفية العثور على مثل هذه الأخطاء الدلالية وأقسم عليها: للإبلاغ عن أن قيمة الإرجاع هي وعد ، ولكن ، لهذا السبب ، لم يتم كتابة الانتظار. ويشمل ذلك أيضًا مشكلات أسلوبية متوسطة التعقيد: استخدام لامدا أو وظيفة ، وما إلى ذلك ، والتي لم يعد بإمكانها القيام بها.
فيما يتعلق بالقواعد البسيطة: موضع الأقواس وعلامات التبويب مقابل المساحات ، وما إلى ذلك ، ويعتقد أنه ينبغي أن تعطى ل Prettier أو حزمة مماثلة. لكن في الحدود الداخلية ، يجب تركها على أي حال: هذه هي الحدود الأخيرة ، والتي لا تزال قادرة على إيقاف المطور المهمل في مجموعة المشروع الساقطة. علاوة على ذلك ، يمكن أتمتة هذا الخط: على سبيل المثال ،
husky ، يسمح لك ببدء تشغيل linter تلقائيًا لكل التزام.
قررنا
عدم ترحيل أي من مجموعات قواعد tslint التي لدينا. وإنشاء مجموعة خاصة بك من الصفر.
هناك مجموعات قواعد محددة مسبقًا لـ eslint:
- ESLint Recommended عبارة عن مجموعة محايدة من القواعد التي تم إنشاؤها بفكرة عدم إنتاج holivars. يتم تضمين عمليات التحقق الضرورية فقط: المتغيرات غير المستخدمة ، إلخ. جميع مجموعات لاحقة تمديد هذا واحد.
- Google - يوجد بالفعل سبب لل holivar: للمسافات البادئة هناك مسافات صارمة ، فاصلة منقوطة مطلوبة.
- AirBnB - هناك أيضًا قواعد صارمة للأسلوب ، بما في ذلك فاصلة منقوطة إلزامية.
- ستاندارت - الفاصلة المنقوطة ممنوعة هنا ، ولكن الفواصل الزائدة ممنوعة أيضًا.
لم نحب أي من الحزم الجاهزة. قد يبدو هذا غريباً ، لكن من المهم بالنسبة لنا أن نتحول إلى لون جديد ، متجنباً الحروب الأسلوبية. إذا كتبنا مثل هذا في كل مكان (علامات التبويب ، بدون فاصلة منقوطة ، فواصل الزائدة إلزامية) ، فدعها تبقى كما هي - الشيء الرئيسي هو أنها هي نفسها في جميع المشاريع.
الجنس الموعود: مجموعة القواعد الخاصة به
بأمانة ، لإظهار مجموعة قواعد eslint مثل فتاة تظهر الثدي: لم تعد هناك أسرار. اعتقدت لفترة طويلة ما إذا كان الأمر يستحق القيام بذلك. لكن بعد التشاور مع الفتيات الأخريات ، قررت أن الأمر يستحق ذلك.
سأبدأ بالمكونات الإضافية التي نستخدمها:
- رد فعل - يتحقق من رمز مكون التفاعل. مجموعة أساسية من القواعد بالإضافة إلى قواعدنا. من المهم: نحن نغرق لمكونات وظيفية نقية.
- react-hooks - قواعد من المطورين رد فعل حول استخدام hooks؛
- الوعد - يتحقق من الأخطاء الشائعة عند استخدام الوعد. وهو يعمل بعض الشيء غريب مع رمز TypeScript. من المهم: نحاول استخدام Promise في كل مكان وعدم استخدام عمليات الاسترجاعات ثم / catch بسبب سهولة قراءة الكود ؛
- optize-regex هو مكون إضافي ممتع يقدم نصائح حول تحسين التعبيرات العادية. ليست مفيدة للغاية ، لأن regexp لدينا بعض الشيء. ولكن بعيدا عن كل تمتلك السحر regexp. إنه مفيد ، لكن لا يوجد الكثير من الأسئلة ؛
- sonarjs هو مكون إضافي للنار مع وجود اختبارات لتعقيد الكود والأخطاء النموذجية لإعادة بناء المساكن. الأول هو شيء مضحك: البرنامج المساعد يقيم التعقيد المتصور للكود ويقدم المشورة عندما يكون الأمر يستحق تبسيط الكود. يتيح البحث عن أخطاء إعادة البناء أيضًا غالبًا تبسيط التعليمات البرمجية أو ، على الأقل ، تحسين إمكانية القراءة ؛
- @ typescript-eslint - قواعد eslint لفحص كود TypeScript. ومجموعة لتعطيل القواعد الأساسية التي لا تتوافق مع TS.
ملف قاعدة لدينا كامل
هنا . ألاحظ أنها ليست عقيدة ويتم تحديثها لأنها تتكيف مع المشاريع.