Tslint: الاقتراح: تكوين نسالة مشروط

إذا وضعت الاختبارات وكود الإنتاج في دلائل منفصلة ، فلن تحتاج إلى مثل هذه الميزة. إذا لم تقدم ملف تكوين كوسيطة CLI ، فإن TSLint تستخدم أقرب tslint.json . لذلك يمكن أن يكون لديك إعدادات مختلفة لمجلدات مختلفة. باستخدام "extends" يمكنك استخدام نفس التكوين الأساسي وتجاوز قواعد محددة فقط.

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

IMO تضيف الميزة المقترحة الكثير من التعقيد. قد لا يكون التنفيذ بهذه الصعوبة ، لكنه يجعل ملف التكوين صعب القراءة والفهم.
إذا أردنا تنفيذ هذا ، فأنا أفضل الاقتراح الثاني.

سنحتاج أيضًا إلى مناقشة كيفية عمله عند توسيع التكوينات. في أي ترتيب يتم تطبيق الإلغاءات؟

صحيح ، يمكنك فقط فصل الكود ، لكنه يضر ببيئة العمل. إما لديك

src/
  tslint.json
  a/
    b/
      c/
test/
  tslint.json (extends ../src)
  a/
    b/
      c/

و c/foo.spec.ts يجب أن يكون import {symbol} from '../../../a/b/c/foo';

يصبح هذا المسار قبيحًا في monorepo حيث تكون الملفات غالبًا عميقة جدًا في الشجرة.

أو لديك

  a/
    src/
      tslint.json
    test/
      tslint.json (extends ../src)
    b/
      src/
        tslint.json
      test/
        tslint.json (extends ../src)
      c/
        src/
           tslint.json
        test/
          tslint.json (extends ../src)

وهو عدد كبير جدًا من ملفات tslint.json

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

// a.json
{"rules": {"foo": [true, 1]}}

// b.json
{"rules": {"foo": [true, 2]}}

// c.json
{
  "extends": ["a.json", "b.json"],
  "rules": {"foo": [true, 3]}
}

سيؤدي إلى احتواء القاعدة "foo" على الوسيطة 3. إذا لم تكن هذه القاعدة في c.json ، فيجب أن يكون لـ "foo" القيمة 2 ، بسبب ترتيب المصفوفة "extends".

بالنسبة لعمليات الإلغاء ، أتوقع أن يتم تطبيق نفس الترتيب. من المنطقي بالنسبة لي استخدام آخر تجاوز يتطابق مع regex المزود ، مع مراعاة الترتيب الذي يتم فيه النظر في قواعد "الامتداد". مثال على ملف واحد:

{
  "rules": {"a": [true, 1]},
  "override": [
    {"match": "test|spec", "rules": {"a": [true, 2]}},
    {"match": "test", "rules": {"a": [true, 3]}}
  ]
}

سيكون لها القيمة 2 للقاعدة "foo" عندما يحتوي مسار الملف على "المواصفات" ، و 3 إذا كان يحتوي على "اختبار" ، و 1 بخلاف ذلك. (من الواضح ، ليست مجموعة مفيدة جدًا من الإلغاءات ، لأن كلمة "اختبار" قد تُحذف أيضًا من الأولى ، لكنك حصلت على الفكرة)

هل هذا منطقي والإجابة على سؤالك؟

calebegg هناك بعض حالات الحافة الأخرى التي يجب مراعاتها:

// a.json
{
  "rules": {"foo": [true, 1]},
  "override": {"match": "test|spec", "rules": {"foo": [true, 2]}}
}

// b.json
{
  "extends": "./a.json"
  "rules": {"foo": false}
}

ما هي النتيجة المتوقعة؟

• 2 لأن الطلب a.json/rules -> b.json/rules -> a.json/override
• false لأن الطلب a.json/rules -> a.json/override -> b.json/rules

كذلك هنا ، ما هي النتيجة المتوقعة:

// c.json
{
  "rules": {"foo": [true, 1]},
  "override": {"match": "test|spec", "rules": {"foo": false}}
}

// d.json
{
  "extends": "./a.json"
  "rules": {"foo": {"options": 2}},
  "override": {"match": "test|spec", "rules": {"foo": {"options": 3}}}
}

مجرد فكرة عشوائية: لماذا لا تقوم فقط بمطابقة الأنماط بالترتيب وتجاوز التطابق السابق (جزئيًا):

{
  "rules": { // same as "*"
    "rule-one": true,
    "rule-two": true
  },
  "*.js?(x)": { // we could get rid of "jsRules" with this
    "rule-two": false
  },
  "*.{t,j}sx": {
    "jsx-rule": true
  },
  "*.spec.*" {
    "rule-one": false
  }
}

بعض الأمثلة:

• foo.ts : القاعدة الأولى ، القاعدة الثانية
• foo.tsx : القاعدة الأولى ، القاعدة الثانية ، قاعدة jsx
• foo.js : القاعدة الأولى
• foo.jsx : القاعدة الأولى ، قاعدة jsx
• foo.spec.tsx : القاعدة الثانية ، قاعدة jsx
• foo.spec.js : لا شيء

أنا فقط لا أعرف مكان وضع هذا داخل ملف config. يجعل المستوى نفسه مثل "rules" الكتابة أسهل ، لكنه قد يربك المستخدمين ، لأنه على نفس مستوى "extends" ، "rulesDirectory" ، ...

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

كما أنه يجعل الكود أكثر تعقيدًا. يتم حاليًا دمج التكوينات أثناء التحليل. مع هذا الاقتراح ، لا يُعرف التكوين النهائي إلا عندما يكون لدينا اسم ملف.

مرحبا،

هذه الميزة ستكون رائعة. أعتقد أن Eslint تدعم هذه الميزة: https://eslint.org/docs/user-guide/configuring#configuration -based-on-glob-pattern. لذلك ، يمكن أن تكون البنية والدلالات هي نفسها ، لتجنب الالتباس.

minomikula شكرا جزيلا. لقد بحثت في مستندات ESLint من قبل ولكن لم أجد هذا القسم.

نهجهم منطقي. كي تختصر:

• "overrides" في التكوين على مصفوفة من التجاوزات
• يمكن أن يحدد التجاوز عدة أنماط للكرة الأرضية ( "files" ). إذا تطابق أحدهما ، فسيتم تطبيق التكوين
• يمكنك استبعاد الملفات بنمط الكرة الأرضية: "excludedFiles"
• ترتبط أنماط الكرة الأرضية بملف التكوين المحدد فيه
• تحتاج أنماط الكرة الأرضية دائمًا إلى مطابقة المسار بالكامل ، وليس الاسم الأساسي فقط
• تتم معالجة التخطي بالترتيب ، مما يؤدي إلى تجاوز السابق
• عند تمديد ملف التكوين ، يتم تقييم التكوين الأساسي بالكامل قبل المتابعة إلى التهيئة الموسعة
  
  
  
  • base.json / القواعد
  
  
  • base.json / تجاوزات
  
  
  • extending.json / القواعد
  
  
  • extending.json / تجاوزات
  
  

هناك بعض الأشياء التي يجب مراعاتها عند نقل هذا السلوك إلى TSLint:

• يجب علينا بالتأكيد تعطيل extends و linterOptions في التخطي
• ربما نريد أيضًا عدم السماح بـ rulesDirectory
• هل نرغب في السماح بتجاوزات rules و jsRules أم هل نلغي jsRules لصالح تجاوز **/*.js?(x) ؟

أفكار أو تعليقاتadidahiyacalebeggalexeagleminomikula؟

أوه ، رائع ، نعم ، هذا النهج يبدو معقولًا بالنسبة لي. كان يجب أن أبحث أيضًا عن حالة التقنية الصناعية السابقة.

سيكون هذا إضافة رائعة! يعمل نهج eslint بشكل رائع عند تعطيل بعض القواعد في ملفات الاختبار بشكل مشروط.

calebegg هل ما زلت تخطط لدفع هذا إلى الأمام عندما تجد الوقت؟

نعم ، أود بالتأكيد العمل على هذا. ajafff هل أنت سعيد عمومًا بالبدء بنهج ESLint والتكرار في العلاقات العامة؟ أو هل تعتقد أن هناك أسئلة تتعلق بالتصميم يجب أن نتحدث عنها أولاً؟

هل نريد السماح بالقواعد و jsRules في التجاوزات أم هل نوقف القواعد js لصالح تجاوز * / .js؟ (x)؟

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

calebegg أنا بخير مع نهج ESLint. لقد طبقت مفهومًا مشابهًا جدًا في وقت تشغيل POC linter https://github.com/fimbullinter/wotan/tree/master/packages/wotan#overrides

قد يكون التكامل في TSLint API الحالي صعبًا ، لأنه يدمج حاليًا جميع التكوينات أثناء التحليل. يجب تأجيل هذا الأمر حتى يتم معرفة اسم الملف ويجب القيام به لكل ملف.

هذا هو بالتأكيد تغيير API كسر.

calebeggmitchlloydajafffalexeagle أرى فائدة تذكر في هذه الميزة على مجرد تعشش tslint.json الملفات لتجاوز التكوينات الخارجية. تعمل هذه الميزة بالفعل اليوم ولا تتطلب أي فواصل معقدة لواجهة برمجة التطبيقات. هل ستتأذى إذا رفضنا هذا الطلب؟

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

هناك الكثير من المشاريع التي تضع ملفات المواصفات في نفس دليل المصادر. لقد أصبح هذا من أفضل الممارسات في العديد من البيئات ، تقوم Angular CLI بإنشاء هيكل مشروع من هذا القبيل وما إلى ذلك. لا أعتقد أن ملفات تهيئة tslint المتداخلة الواقعية ستعمل مع كل هؤلاء الأشخاص.

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

giladgray يدعم التغيير المطلوب سيناريو يضع فيه المستخدمون اختباراتهم وملفات الإنتاج بجوار بعضهم البعض مثل هذا:

some-dir/
  my-component.ts
  my-component.test.ts

كيف يمكن أن يعالج "تداخل ملفات tslint.json " حالة الاستخدام هذه عندما نريد قواعد مختلفة لـ my-component.ts و my-component.test.ts ؟

توصي إرشادات angulargiladgray بوضع اختباراتك جنبًا إلى جنب مع ملفاتك. لذا فإن 99٪ من المشاريع الزاويّة تفعل ذلك. نظرًا لكون tslint إلى الوراء ، كان كل مشروع زاوية عملت فيه يعاني من مشكلات. تعليقك الأخير محير وقصير النظر. إذا كنت لا تستطيع / لا ترغب في قبول هذا الاقتراح المفيد بشكل لا يصدق ، فأعتقد أنك متحفظ للغاية بحيث لا يمكنك اتخاذ القرارات نيابة عننا في مثل هذا المشروع المهم. كانت هذه المشكلة تجعل مشروعنا الزاوي العمل صعبًا لسنوات.

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

من المنطقي أن تريد تجاوزات للملفات التي لا تتناسب مع بنية متداخلة كما هو مذكور أعلاه. يبدو لي أن تعليق giladgray كان يهدف إلى تحديد ما إذا كان لا يزال هناك اهتمام كبير من المجتمع بهذا التغيير ، نظرًا لعدم وجود أي نشاط بشأن هذه المشكلة لأكثر من 6 أشهر. يتضح هذا بشكل خاص من خلال تعليقه على العلاقات العامة المفتوحة (# 3708):

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

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

هل هناك أي تحديث في هذا الموضوع؟
الفكرةajafff المقترحة في كتابه تلخيص تعليق تبدو معقولة ويرضي كل مجموعة متنوعة من الاحتياجات. يعد استخدام نفس الدلالات مثل eslint طريقة جيدة للمضي قدمًا.

كما علقت على # 1063 ذي الصلة ، ستكون حالة الاستخدام الخاصة بي هي استخدام قنابل tslint-microsoft-contrib حاليًا على مكونات ملف Vue الفردي لبعض القواعد. قد يكون هذا إما مشكلة Vue ، أو مشكلة TSLint ، وقد تقوم هذه الفرق أو لا تعمل على حل المشكلة المحددة - يبدو تعطيل القواعد المخالفة حتى يحدث ذلك كحل بسيط ليس مرهقًا للغاية. مقارنة بضرورة إضافة نفس توجيه التعطيل إلى كل ملف .vue فردي ، وتحديثه في جميع تلك الأماكن حيث تتغير القاعدة. كما أنه ليس من المنطقي تقسيم المشروع إلى ملفات .vue و .ts ، فسيكون هيكلًا محرجًا للغاية.

أنا أؤيد هذه الميزة القادمة. ربما يمكننا أيضًا حل طلب tslintignore بشكل نظيف في # 73 باستخدامه من خلال السماح لبعض التجاوزات بتعطيل جميع القواعد تمامًا؟

{
    "files": "./src/test-data/*.ts",
    "reset": true // Resets tslint.json to {}
}

تقوم tslint-microsoft-contrib حاليًا بقنابل على مكونات ملف Vue الفردي لبعض القواعد

أوه 😕millimoose هل يمكنك تسجيل مشكلة في tslint-microsoft-contrib؟

JoshuaKGoldberg - لقد قمت بالفعل بإعداد تقرير مفصل عن هذا الخطأ في @ vuejs / vue-cli والذي بدا أنه الأنسب. (تم وضع علامة على أنها "تنتظر التكاثر" لذا أعتقد أنها ليست في غير محلها بشكل كبير). لقد ذكرت للتو أنها حافز للتناسل هنا. إنه نوع من الأشياء التي يمكن أن تتحقق في نظام إيكولوجي متطور ، والتي يجب أن تكون حجة على أن تكون الأدوات مرنة بما يكفي للتغلب على العقبات دون كتابة الاختراقات فعليًا حول أخطاء الآخرين.

أي تعديل حدث في هذه القضية؟

تم وضع علامة على هذه المشكلة حاليًا على أنها "تحتاج إلى اقتراح" ، لكنني أعتقد أننا بالفعل اقتراح في https://github.com/palantir/tslint/issues/3447#issuecomment -344020834؟

RoystonSajafff ذكر الصورة اقتراح بعض المغفلة التي ينبغي تناولها:

هناك بعض الأشياء التي يجب مراعاتها عند نقل هذا السلوك إلى TSLint:

• يجب علينا بالتأكيد تعطيل extends و linterOptions في التخطي
• ربما نريد أيضًا عدم السماح بـ rulesDirectory
• هل نرغب في السماح بتجاوزات rules و jsRules أم هل نلغي استخدام jsRules لصالح تجاوز **/*.js?(x) ؟

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

فقط عثرت على هذا بنفسي ، وأريد فقط التعبير عن اهتمامي بهذا النوع من الميزات.

انتهى بنا المطاف بتخفيف بعض قواعد الفحص التي تؤثر على كود الإنتاج ودعونا نرى كيف ستسير الأمور. ):

أحب أن أرى هذه الميزة

الاشتراك - تحتاج هذا أيضًا.

أحتاج هذا بشدة :(

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

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

أشك بشدة في أن هذه الميزة سيتم تنفيذها على الإطلاق ، لا يبدو أن tslint يتم صيانته بشكل فعال بشكل عام. أقترح التبديل إلى @typescript-eslint ، فقد حصل على دعم كامل من مشاريع eslint و ts وأصبح الترحيل أسهل من أي وقت مضى باستخدام @ typescript-eslint / eslint-plugin-tslint . وهناك جدول متوافق مع tslint وقواعد eslint المقابلة / البدائل الأخرى المتاحة. يعد إعداد Eslint قابلاً للتخصيص بدرجة كبيرة ، لذلك لا أرى أي نقطة في التمسك بـ tslint.

أقترح تطبيق مفهوم استخدامات مستودع git للملفات الموجودة في .gitIgnore ... على قواعد tsLint. استخدام موقعك الهرمي الحالي كسياق للغة اللتر ، جنبًا إلى جنب مع ملف تجاوز ، عند فحص دليل فرعي معين. ثم يمكنك تضمين أو استبعاد أو إعداد أي تكوين في أي مستوى دليل تريده.

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

redevill يساعد الأشخاص في كتابة الاختبار في مجلد test . لكن لا يوجد اختبار كتابي واحد مثل something.test.ts في نفس مجلد المكون / الخدمة.

متفق عليه - ولكن مع تغيير طفيف: (يمكن تشغيله تلقائيًا باستخدام منشئ القوالب (نمط CLI)
MyComponentDir
- MyComponentTestsDir
------ tslint.test.json
------ شيء اختبار
- mycomponent.component.css
- mycomponent.component.html
- mycomponent.component.ts

الفكرة يمكن أن تعمل.

معجب كبير بهذا الاقتراح. نعم من فضلك! أفضّل أن يكون مفهوم Overrides.

راجع للشغل ، نظرًا لإعلان الإيقاف لـ tslint ، لا يمكنني _ حقًا _ تخيل أن مثل هذا التغيير الكبير سيتم إجراؤه في هذه المرحلة ، وينتقل فريقي إلى eslint ، والذي يحتوي بالفعل على تسهيلات تجاوز لكل قاعدة + لكل ملف.

الاعلان السابق: https://medium.com/palantir/tslint-in-2019-1a144c2317a9

RoystonS صحيح بشكل أساسي ، لن تتم إضافة مثل هذه الميزة الكبيرة إلى tslint في هذه المرحلة. انظر # 4534

نحن نستخدم مشروع Angular. نحن بحاجة إلى مفهوم التجاوزات. خلاف ذلك ، من الألم إدارة