Html5-boilerplate: RFC: الهجرة إلى ESLint

أي واحد؟ أنا راضٍ عن ترك الوضع الراهن. برنامج ESLint رائع ، لكنني سأحتاج إلى الاقتناع لإجراء التغيير (ومن ثم يتعين على شخص ما _ إجراء_ التغيير في العلاقات العامة.) سأترك هذا مفتوحًا لأسبوع آخر وإذا لم يكن هناك أي إجراء سأغلقه.

يمكنني العلاقات العامة لهذا. يمكن القول إن ESLint هي إحدى الأدوات الأكثر استخدامًا في نظام جافا سكريبت البيئي.

http://www.npmtrends.com/eslint-vs-jshint

roblarsen أنا تمامًا مع amilajack في هذا ،
لقد أجريت مقارنة موجزة بين الاثنين ببعض البيانات التي جمعتها من الويب إذا كنت تريد إلقاء نظرة.

شكرا يا شباب. هذه أشياء رائعة. أي شخص آخر يريد أن تتناغم؟

amilajack شكرا على العرض للعلاقات العامة. إنه حقًا موضع تقدير.

roblarsen على الرحب والسعة!
amilajack لا تتردد في مراسلتي إذا كنت بحاجة إلى أي مساعدة. :عامل بناء:

amilajack هل ما زلت تعمل على هذا؟

ryzokuken هناك

أوصي بالاطلاع على المعيار الذي يتم إضافته أعلى ESLint ، وهو شائع جدًا. لنكون صادقين ، من المفيد أن تتوقف أخيرًا عن الحفاظ على تكوينات ESLint ...

ArmorDarks على الرغم من أنني أحب الأسلوب القياسي ، لا أعتقد أنه من الجيد

بقدر ما أحب مرونة لغة البرمجة ، فإن هذه الميزة لها ثمن ، والسؤال هو ما إذا كنا على استعداد لدفع هذا السعر. إن القواعد الأكثر صرامة تجعل الكود أسهل في الفهم وأكثر موثوقية كنتيجة لذلك ، حتى مع نمو المشروع.

علاوة على ذلك ، تربح الفاصلة المنقوطة من حيث الشعبية ، مع الأخذ في الاعتبار دليل أسلوب JavaScript من Airbnb كمثال: أحد أكثر المستودعات المميزة بنجمة على GitHub وأرقام التنزيل الأعلى على NPM. [1] [2] [3] [4]

أيضًا ، سنحتاج إلى تحديث جميع ملفات جافا سكريبت ، لأنهم جميعًا يستخدمون الفواصل المنقوطة بالفعل. [5] [6]

لذلك ، لا أعتقد أن هذا الموضوع يستحق تناول الدراجات .

المراجع:

[1] https://github.com/airbnb/javascript
[2] https://www.npmjs.com/package/eslint-config-airbnb-base
[3] https://www.npmjs.com/package/eslint-config-airbnb
[4] https://www.npmjs.com/package/eslint-config-standard
[5] https://github.com/h5bp/html5-boilerplate/blob/master/gulpfile.babel.js
[6] https://github.com/h5bp/html5-boilerplate/blob/master/src/js/plugins.js

كل هذا سوف يتلخص في الخلافات حول أسلوب التشفير على أي حال. أنا فقط أقترح بديلًا تم اختباره في المعركة.

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

في هذه المرحلة ، أريد التبديل إلى eslint بأقل مقاطعة ممكنة. يتضمن ذلك التخلص من القواعد الحالية التي نطبقها بالجملة دون مناقشة على الأقل بشأن القواعد الجديدة التي يجب أن تكون (وهذا هو السبب في أن العلاقات العامة الحالية لـ eslint هي DOA.)

سأموت على تلة الفاصلة المنقوطة ، على سبيل المثال.

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

سأموت على تلة الفاصلة المنقوطة ، على سبيل المثال.

هذه مجرد ضربات قليلة مع regex ، كما تعلم. ولكن ما إذا كان استخدامها أم لا بالنسبة لبعض الأشخاص يبدو بالفعل أنه موضوع مؤلم ...

لن نقوم بشحن eslintrc في المنطقة. الفائدة الحقيقية ، من حيث المشروع ، هي أننا نقوم بذلك ويمكن أن تكون بمثابة مثال لما يجب أن يبدو عليه مطور الويب الجيد.

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

القضية الحقيقية هي ما يجب اعتباره معيار المجتمع في عالم JS.

نقاط جيدة. من الجيد أن نتذكر تأثيرات المصب حتى لكمية صغيرة من JS نقوم بشحنها.

ولتوضيح أنني لست ضد إجراء التغييرات. ما لا أريد القيام به هو إجراء تغييرات بالجملة دون مناقشة (لذا شكرًا لكوني جزءًا من المناقشة 👍) بينما أنا مستميت إلى حد ما للحصول على 6.0 من الباب في الوقت الحالي ، فأنا بشكل عام لست مستعجلًا لإجراء تغييرات هنا ما لم تكن التغييرات الصحيحة.

أحد الخيارات هو تطبيق الإعداد eslint:recommended الذي يُبلغ عن المشكلات الشائعة ، لكنه لا يفرض تفضيلات الأسلوب. في هذه الحالة ، تعمل ESLint فقط على منع الأخطاء والأخطاء. إنه حقًا نوع من الحد الأدنى من التكوين الفطرة السليمة.

القواعد الوحيدة المتعلقة بالنمط التي أقترح إضافتها في هذه الحالة هي تلك الموجودة في .editorconfig : لا توجد مسافات بيضاء ، 4 مسافات بادئة ، وأسطر جديدة نهائية.

4 مسافات بادئة

للحصول على المعلومات فقط ، لم يعد أي من أنماط التعليمات البرمجية الشائعة التي تستخدم 4 مسافات مسافة بادئة.

https://github.com/h5bp/html5-boilerplate/issues/1913#issuecomment -377298563 (eslint: توصية) يبدو جيدًا ، على الرغم من أن لدي تفضيل شخصي لـ https://github.com/h5bp/html5-boilerplate/ القضايا / 1913 # issuecomment -318050971 (StandardJS).

مازحا: https://github.com/christophwitzko/semicolon-indent#semicolon -indent

أنا مع Standard أيضًا ، لأنهم لا يحافظون فقط على التكوين الجيد مع التحقق من الصحة من خلال المجتمع ولكن أيضًا يشحنون الإضافات المختبرة الممتازة أعلى ESLint.

ولكن لكي أكون منصفًا ، يجب أن أذكر أيضًا أجمل . رغم ذلك ، لا يزال تصويتي يقف لصالح Standard.

تذكير من وقت سابق في المناقشة

سأموت على تلة الفاصلة المنقوطة ، على سبيل المثال.

تخيل أنها لعبة نجت ، ومثلما كنا في عام 2005 نقرر بين علامات التبويب مقابل المسافات.

راجع للشغل ، تجدر الإشارة إلى الشيء المتعلق بـ Prettier - يجب إقرانه بتكوين ESLint جيد ، لأن معظم ما تحتفظ به Prettier هو نمط الكود ، بينما تكوينات ESLint (وخاصة التكوينات القياسية) تغطي أيضًا الكثير من الممارسات الجيدة أو السيئة غير الأسلوبية.