Tslint: प्रस्ताव: सशर्त एक प्रकार का वृक्ष विन्यास

को निर्मित 3 नव॰ 2017 · 42टिप्पणियाँ · स्रोत: palantir/tslint

ऐसी कुछ स्थितियां हैं जहां हम सशर्त रूप से एक लिंट चेक लागू करना चाहते हैं, इस आधार पर कि कोड को लिंट किया जा रहा है या नहीं, परीक्षण कोड है या नहीं। उदाहरण के लिए, हम उत्पादन कोड से 'किसी' को प्रतिबंधित करना चाहते हैं, क्योंकि यह असुरक्षित है। लेकिन परीक्षणों में, 'कोई भी' सेवाओं के नकली या नकली कार्यान्वयन की आपूर्ति करने के लिए, या इसके माध्यम से डालने के लिए उपयोगी हो सकता है ताकि आप निजी तरीकों को कॉल कर सकें। या हम परीक्षण बनाम उत्पादन कोड में विधियों के एक अलग सेट पर प्रतिबंध लगाना चाह सकते हैं, उदाहरण के लिए।

मैं जो प्रस्तावित करता हूं वह फ़ाइल नाम पर रेगेक्स मैच के आधार पर लिंट चेक को सशर्त रूप से सक्षम करने का एक तरीका है। यह कुछ निर्देशिकाओं (उदाहरण के लिए "विरासत" कोड युक्त), या .tsx या .d.ts फ़ाइलों आदि के लिए लिंट चेक को बंद करने के लिए भी उपयोगी हो सकता है।

यहाँ कुछ वाक्य रचना स्ट्रॉमैन विचार हैं; मैं सुझावों के लिए भी खुला हूं।

अनुभाग वस्तु

{
  "rules": {
    "no-any": {"other": true},
    "no-console":
        {
          "test": [true, "warn", "error"], 
          "other": [true, "log", "warn", "error"]
        }
  },
  "sections": {
    "test": ".*\\.spec\\.ts$"
  }
}

"अन्य" ऐसी चीजें होंगी जो किसी भी रेगेक्स से मेल नहीं खातीं। यह बहुत संक्षिप्त है, लेकिन मुझे लगता है कि नियम खंड की पठनीयता थोड़ी प्रभावित होती है।

"ओवरराइड" नियम

{
  "rules": {
    "no-any": true,
    "no-console": [true, "log", "warn", "error"]
  },
  "override": {
    "match": ".*\\.spec\\.ts$",
    "rules": {
      "no-any": false,
      "no-console": [true, "warn", "error"]
    }
  }
}

(यह शायद एक सरणी होनी चाहिए, कई ओवरराइड के लिए भी अनुमति देने के लिए)।

Declined Enhancement

स्रोत

calebegg

👍85 ❤9

सबसे उपयोगी टिप्पणी

नेस्टिंग यहां चर्चा किए गए मुद्दों को हल नहीं करता है। बहुत से लोग चाहते हैं कि उनके परीक्षण उसी निर्देशिका संरचना में हों, जिस कोड का यह परीक्षण करता है, और tslint के साथ अभी ऐसा करने का कोई अच्छा तरीका नहीं है।

DanielSchaffer 28 जुल॰ 2018

👍26

सभी 42 टिप्पणियाँ

यदि आप अपने परीक्षण और उत्पादन कोड को अलग-अलग निर्देशिकाओं में रखते हैं, तो आपको ऐसी सुविधा की आवश्यकता नहीं होगी। यदि आप CLI तर्क के रूप में एक कॉन्फ़िग फ़ाइल प्रदान नहीं करते हैं, तो TSLint निकटतम tslint.json का उपयोग करता है। इसलिए आपके पास अलग-अलग फ़ोल्डरों के लिए अलग-अलग सेटिंग्स हो सकती हैं। "extends" का उपयोग करके आप समान आधार कॉन्फ़िगरेशन का उपयोग कर सकते हैं और केवल विशिष्ट नियमों को ओवरराइड कर सकते हैं।

मुझे लगता है कि कई कोणीय और प्रतिक्रिया परियोजनाएं उसी निर्देशिका में संबंधित उत्पादन कोड के रूप में परीक्षण करती हैं। व्यक्तिगत रूप से मुझे लगता है कि यह एक बुरा अभ्यास है। मैंने उत्पादन कोड में परीक्षणों से प्रतीकों को आयात करने वाले पर्याप्त लोगों (गलती से) को देखा है।

आईएमओ प्रस्तावित सुविधा बहुत जटिलता जोड़ती है। कार्यान्वयन इतना कठिन नहीं हो सकता है, लेकिन यह कॉन्फ़िगरेशन फ़ाइल को पढ़ने और समझने में मुश्किल बनाता है।
अगर हम इसे लागू करने जा रहे हैं, तो मैं दूसरा सुझाव पसंद करूंगा।

हमें यह भी चर्चा करनी होगी कि कॉन्फ़िगरेशन का विस्तार करते समय यह कैसे काम करता है। ओवरराइड किस क्रम में लागू होते हैं?

ajafff 3 नव॰ 2017

👎21

सच है, आप कोड को अलग कर सकते हैं, लेकिन यह एर्गोनॉमिक्स को नुकसान पहुंचाता है। या तो आपके पास है

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';

हमारे मोनोरेपो में वह रास्ता बदसूरत हो जाता है जहां फाइलें अक्सर पेड़ में बहुत गहरी होती हैं।

या आपके पास है

  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 फ़ाइलें हैं

alexeagle 3 नव॰ 2017

👍7

ओवरराइड के विषय पर: मैं कहूंगा कि ओवरराइड उसी क्रम में लागू होते हैं नियम लागू होते हैं। मुझे नहीं पता कि वह क्या है, और मुझे दस्तावेज़ीकरण नहीं मिला, लेकिन सहज रूप से मुझे लगता है कि यह इस तरह होगा:

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

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

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

3 तर्क वाले नियम "foo" का परिणाम होगा। यदि वह नियम c.json , तो "विस्तारित" सरणी के क्रम के कारण "foo" का मान 2 होना चाहिए।

ओवरराइड के लिए, मैं वही आदेश लागू करने की अपेक्षा करता हूं। मेरे लिए अंतिम ओवरराइड का उपयोग करना समझ में आता है जो आपूर्ति किए गए रेगेक्स से मेल खाता है, उस क्रम को ध्यान में रखते हुए जिसमें 'विस्तार' नियमों पर विचार किया जाता है। एक एकल फ़ाइल उदाहरण:

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

नियम "फू" के लिए मान 2 होगा जब फ़ाइल पथ में "कल्पना" होता है, 3 यदि इसमें "परीक्षण" होता है, और 1 अन्यथा। (जाहिर है, ओवरराइड का एक बहुत उपयोगी सेट नहीं है, क्योंकि "परीक्षण" को पहले से भी छोड़ा जा सकता है, लेकिन आपको यह विचार मिलता है)

क्या यह समझ में आता है और आपके प्रश्न का उत्तर देता है?

calebegg 3 नव॰ 2017

@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}}}
}

ajafff 3 नव॰ 2017

बस एक यादृच्छिक विचार: क्रम में पैटर्न से मिलान क्यों न करें और (आंशिक रूप से) पिछले मैच को ओवरराइड करें:

{
  "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 : नियम-एक, जेएसएक्स-नियम
foo.spec.tsx : नियम-दो, जेएसएक्स-नियम
foo.spec.js : कोई नहीं

मुझे नहीं पता कि इसे कॉन्फ़िगरेशन के अंदर कहां रखा जाए। "rules" समान स्तर लिखना आसान बनाता है, लेकिन उपयोगकर्ताओं को भ्रमित कर सकता है, क्योंकि यह "extends" , "rulesDirectory" के समान स्तर पर है, ...

एक और समस्या कॉन्फ़िगरेशन का विस्तार कर रही है। यदि हम मूल कॉन्फ़िगरेशन से सभी ओवरराइड लागू करते हैं और फिर वर्तमान कॉन्फ़िगरेशन से ओवरराइड करते हैं, तो इसे समझना मुश्किल है।

यह कोड को और अधिक जटिल बनाता है। वर्तमान में कॉन्फ़िगरेशन को पार्सिंग के दौरान मर्ज कर दिया गया है। इस प्रस्ताव के साथ अंतिम कॉन्फ़िगरेशन केवल तभी ज्ञात होता है जब हमारे पास फ़ाइल नाम होता है।

ajafff 12 नव॰ 2017

नमस्ते,

यह फीचर बहुत अच्छा होगा। मुझे लगता है कि एस्लिंट इस सुविधा का समर्थन कर रहा है: https://eslint.org/docs/user-guide/configuration#configuration -based-on-glob-patterns। तो, भ्रम से बचने के लिए वाक्य रचना और शब्दार्थ समान हो सकते हैं।

minomikula 13 नव॰ 2017

👍13

@minomikula बहुत बहुत धन्यवाद। मैंने पहले ESLint दस्तावेज़ों की खोज की लेकिन यह खंड नहीं मिला।

उनका दृष्टिकोण समझ में आता है। संक्षेप में:

कॉन्फ़िगरेशन में "overrides" अनुभाग में ओवरराइड की एक सरणी है
एक ओवरराइड एकाधिक ग्लोब पैटर्न निर्दिष्ट कर सकता है ( "files" )। यदि उनमें से एक मेल खाता है, तो कॉन्फ़िगरेशन लागू होता है
आप ग्लोब पैटर्न द्वारा फ़ाइलों को बाहर कर सकते हैं: "excludedFiles"
ग्लोब पैटर्न उस कॉन्फिग फाइल के सापेक्ष होते हैं जिसमें वे निर्दिष्ट होते हैं
ग्लोब पैटर्न को हमेशा पूरे पथ से मेल खाना चाहिए, न कि केवल बेसनाम
ओवरराइड को क्रम में संसाधित किया जाता है, पिछले वाले को ओवरराइड करते हुए
कॉन्फिग फाइल को एक्सटेंड करते समय, एक्सटेंडिंग कॉन्फिग को जारी रखने से पहले बेस कॉन्फिग का पूरी तरह से मूल्यांकन किया जाता है
- बेस.जेसन/नियम
- बेस.जेसन/ओवरराइड्स
- एक्सटेंडिंग.जेसन/रूल्स
- एक्सटेंडिंग.जेसन/ओवरराइड्स

इस व्यवहार को TSLint पर पोर्ट करते समय कुछ बातों पर ध्यान देना चाहिए:

हमें निश्चित रूप से extends और linterOptions को ओवरराइड में अक्षम करना चाहिए
हम शायद rulesDirectory को भी अस्वीकार करना चाहते हैं
हम अनुमति देने के लिए करना चाहते हैं rules और jsRules ओवरराइड की या हम विरोध करते करते jsRules एक के पक्ष में **/*.js?(x) ओवरराइड?

विचार या टिप्पणियां @adidahiya @calebegg @alexeagle @minomikula?

ajafff 13 नव॰ 2017

👍14 ❤6

ओह, वाह, हाँ, वह दृष्टिकोण मुझे उचित लगता है। मुझे पूर्व कला की भी तलाश करनी चाहिए थी।

calebegg 16 नव॰ 2017

यह एक बढ़िया अतिरिक्त होगा! परीक्षण फ़ाइलों में कुछ नियमों को सशर्त रूप से अक्षम करते समय एस्लिंट दृष्टिकोण बहुत अच्छा काम करता है।

Patrik-Lundqvist 12 जन॰ 2018

@calebegg क्या आप अभी भी समय मिलने पर इसे आगे बढ़ाने की योजना बना रहे हैं?

alexeagle 12 जन॰ 2018

हां, मैं निश्चित रूप से इस पर काम करना चाहूंगा। @ajafff क्या आप आम तौर पर ESLint दृष्टिकोण से शुरू करने और पीआर में पुनरावृत्ति से खुश हैं? या क्या आपको लगता है कि ऐसे डिज़ाइन प्रश्न हैं जिनके बारे में हमें पहले बात करनी चाहिए?

क्या हम नियमों और jsRules को ओवरराइड में अनुमति देना चाहते हैं या क्या हम एक */ .js?(x) ओवरराइड के पक्ष में jsRules को हटा देते हैं?

मेरे लिए पदावनत करना समझ में आता है, लेकिन मैं किसी भी तरह से बहुत दृढ़ता से महसूस नहीं करता।

calebegg 24 जन॰ 2018

👍1

@calebegg मैं ESLint दृष्टिकोण के साथ ठीक हूँ। मैंने अपने पीओसी लिंटर रनटाइम में एक बहुत ही समान अवधारणा को लागू किया https://github.com/fimbullinter/wotan/tree/master/packages/wotan#overrides

वर्तमान TSLint API में एकीकरण कठिन हो सकता है, क्योंकि वर्तमान में यह पार्स करते समय सभी कॉन्फ़िगरेशन को मर्ज कर देता है। इसे तब तक स्थगित करने की आवश्यकता है जब तक कि फ़ाइल का नाम ज्ञात न हो और प्रत्येक फ़ाइल के लिए ऐसा करने की आवश्यकता न हो।

यह निश्चित रूप से एक ब्रेकिंग एपीआई परिवर्तन है।

ajafff 1 फ़र॰ 2018

@calebegg @mitchlloyd @ajafff @alexeagle मुझे बाहरी कॉन्फ़िगरेशन को ओवरराइड करने के लिए केवल tslint.json फ़ाइलों को नेस्ट करने पर इस सुविधा में बहुत कम लाभ दिखाई देता है। वह सुविधा पहले से ही आज काम कर रही है और इसके लिए किसी जटिल एपीआई ब्रेक की आवश्यकता नहीं है। अगर हम इस अनुरोध को अस्वीकार कर देते हैं तो क्या आप नाराज होंगे?

giladgray 28 जुल॰ 2018

👎20

DanielSchaffer 28 जुल॰ 2018

👍26

स्रोत के समान निर्देशिका में विशेष फ़ाइलें डालने वाली बहुत सारी परियोजनाएं हैं। यह कई वातावरणों में सबसे अच्छा अभ्यास बन गया है, कोणीय सीएलआई उस तरह की एक परियोजना संरचना उत्पन्न करता है। मुझे नहीं लगता कि यह यथार्थवादी नेस्टिंग tslint कॉन्फ़िगरेशन फ़ाइलें इन सभी लोगों के लिए काम करने जा रही हैं।

mgol 28 जुल॰ 2018

👍17

मैं सहमत हूं कि मेरी परियोजना संरचना को लाइनिंग टूल द्वारा निर्धारित नहीं किया जाना चाहिए। इसके बजाय लाइनिंग टूल को सामान्य मौजूदा पैटर्न का समर्थन करना चाहिए। कॉलोकेटिंग टेस्ट और सोर्स फाइल्स एक सामान्य पैटर्न है।

hoovercj 28 जुल॰ 2018

👍21

@giladgray अनुरोधित परिवर्तन एक ऐसे परिदृश्य का समर्थन करता है जहां उपयोगकर्ता अपने परीक्षण और उत्पादन फाइलें एक दूसरे के बगल में इस तरह रखते हैं:

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

जब हम my-component.ts और my-component.test.ts लिए अलग-अलग नियम चाहते हैं, तो "नेस्टिंग tslint.json फ़ाइलें" इस उपयोग के मामले को कैसे संबोधित करेंगी?

mitchlloyd 29 जुल॰ 2018

👍12

@giladgray कोणीय दिशानिर्देश अनुशंसा करते हैं कि आप अपने परीक्षणों को अपनी फाइलों के साथ रखें। तो 99% कोणीय परियोजनाएं ऐसा करती हैं। tslint के पीछे की ओर होने के कारण मैंने जिस भी कोणीय परियोजना पर काम किया, उसमें समस्याएँ थीं। आपकी अंतिम टिप्पणी भ्रमित करने वाली और अदूरदर्शी है। यदि आप इस अविश्वसनीय रूप से उपयोगी सुझाव को स्वीकार नहीं करना चाहते/नहीं कर सकते हैं, तो मुझे लगता है कि आप इतने रूढ़िवादी हैं कि इतनी महत्वपूर्ण परियोजना पर हमारे लिए निर्णय लेने वाले नहीं हैं। यह समस्या वर्षों से हमारी कोणीय परियोजना के काम को कठिन बना रही है।

insidewhy 29 जुल॰ 2018

👎15 😕1 👍1

@ohjames चलो विषय पर

DanielSchaffer 30 जुल॰ 2018

👍24 🎉1 👎1

यह उन फ़ाइलों के लिए ओवरराइड करना समझ में आता है जो ऊपर बताए अनुसार नेस्टेड संरचना में फिट नहीं होती हैं। मुझे ऐसा लगता है कि @giladgray की टिप्पणी का उद्देश्य यह निर्धारित करना था कि क्या इस परिवर्तन में अभी भी महत्वपूर्ण सामुदायिक हित थे, यह देखते हुए कि इस मुद्दे पर 6 महीने से अधिक समय से कोई गतिविधि नहीं हुई थी। यह खुले पीआर (#3708) पर उनकी टिप्पणी से विशेष रूप से प्रमाणित है:

यदि आप इसे आगे बढ़ाना चाहते हैं, तो कृपया इस शाखा को अपडेट करें ताकि हम इसकी समीक्षा कर सकें, या अब प्रासंगिक न होने पर इसे बंद कर दें। यदि दो सप्ताह में आपसे कोई जवाब नहीं मिलता है तो हम इसे बंद कर देंगे।

@ohjames मैं आपको अपनी टिप्पणी पर पुनर्विचार करने का सुझाव दूंगा - जैसा कि

johnwiseheart 30 जुल॰ 2018

👍6 👎1

क्या इस विषय पर कोई अपडेट है?
@ajafff द्वारा अपनी संक्षिप्त टिप्पणी में प्रस्तावित विचार उचित लगता है और सभी प्रकार की आवश्यकताओं को पूरा करता है। एस्लिंट के समान शब्दार्थ का उपयोग करना आगे बढ़ने का एक अच्छा तरीका है।

k-g-a 6 सित॰ 2018

👍12

जैसा कि मैंने संबंधित #1063 पर टिप्पणी की है, मेरा उपयोग मामला यह होगा कि tslint-microsoft-contrib का उपयोग वर्तमान में कुछ नियमों के लिए Vue एकल-फ़ाइल घटकों पर बम है। यह या तो एक Vue समस्या हो सकती है, या एक TSLint समस्या हो सकती है, और वे टीमें विशिष्ट समस्या को ठीक करने के लिए इधर-उधर हो सकती हैं या नहीं भी हो सकती हैं - ऐसा होने तक आपत्तिजनक नियमों को अक्षम करना एक साधारण समाधान की तरह लगता है जो बहुत बोझिल नहीं है। या तो हर एक .vue फ़ाइल में एक ही अक्षम निर्देश जोड़ने की तुलना में, और नियम समर्थन परिवर्तन के रूप में उन सभी स्थानों पर इसे अपडेट करें। किसी प्रोजेक्ट को .vue और .ts फाइलों में विभाजित करने का कोई मतलब नहीं है, यह एक बहुत ही अजीब संरचना होगी।

millimoose 11 अक्तू॰ 2018

मैं इस सुविधा के आने के पक्ष में हूं। हो सकता है कि हम tslintignore अनुरोध को #73 में इसके साथ कुछ ओवरराइड की अनुमति देकर सभी नियमों को पूरी तरह से अक्षम करने की अनुमति देकर सफाई से हल कर सकें?

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

tslint-microsoft-contrib वर्तमान में कुछ नियमों के लिए Vue सिंगल-फाइल घटकों पर बम गिराता है

ओह @millimoose क्या आप कृपया tslint-microsoft-contrib पर कोई समस्या दर्ज कर सकते हैं?

JoshuaKGoldberg 7 नव॰ 2018

@JoshuaKGoldberg - मैं पहले से ही उस बग की एक विस्तृत रिपोर्ट @ vuejs/vue-cli में कर चुका हूं जो सबसे उपयुक्त लग रहा था। (इसे "प्रतीक्षा में प्रजनन" के रूप में चिह्नित किया गया है, इसलिए मुझे लगता है कि यह बेतहाशा जगह से बाहर नहीं है।) मैंने इसे यहां चिमिंग के लिए एक प्रेरक के रूप में उल्लेख किया है। यह एक ऐसी चीज है जो एक विकसित पारिस्थितिकी तंत्र में फसल कर सकती है और होगी, जो कि वास्तव में दूसरों के बग के आसपास हैक लिखने के बिना बाधाओं के आसपास काम करने के लिए पर्याप्त लचीला उपकरण होने का तर्क होना चाहिए।

millimoose 7 नव॰ 2018

👍2

इस मुद्दे पर कोई अपडेट?

100terres 14 दिस॰ 2018

👍3

इस मुद्दे को वर्तमान में 'प्रस्ताव की आवश्यकता है' के रूप में चिह्नित किया गया है, लेकिन मुझे लगता है कि हम पहले से ही https://github.com/palantir/tslint/issues/3447#issuecomment -344020834 में एक प्रस्ताव रखते हैं?

RoystonS 24 दिस॰ 2018

@RoystonS @ajafff के प्रस्ताव में कुछ ढीले सिरों का उल्लेख किया गया है जिन्हें संबोधित किया जाना चाहिए:

इस व्यवहार को TSLint पर पोर्ट करते समय कुछ बातों पर ध्यान देना चाहिए:
हमें निश्चित रूप से extends और linterOptions को ओवरराइड में अक्षम करना चाहिए
हम शायद rulesDirectory को भी अस्वीकार करना चाहते हैं
हम अनुमति देने के लिए करना चाहते हैं rules और jsRules ओवरराइड की या हम विरोध करते करते jsRules एक के पक्ष में **/*.js?(x) ओवरराइड?

आगे बढ़ने से पहले इस पर palantirtech org के लोगों की सहमति भी होनी चाहिए, क्योंकि यह एक बहुत ही महत्वपूर्ण विशेषता है।

JoshuaKGoldberg 24 दिस॰ 2018

बस इस पर ठोकर खाई, और इस तरह की सुविधा के लिए बस मेरी दिलचस्पी को आवाज देना चाहता हूं।

हमने लाइनिंग के कुछ नियमों में ढील दी है जो उत्पादन कोड को प्रभावित करते हैं और देखते हैं कि यह कैसा होता है। ):

alfaproject 8 जन॰ 2019

👍1

मुझे यह सुविधा देखना अच्छा लगेगा

VincentLanglet 8 जन॰ 2019

सदस्यता लेना - इसकी भी आवश्यकता है।

thejuan 9 जन॰ 2019

मुझे इसकी बहुत आवश्यकता है :(

Mboulianne 9 जन॰ 2019

👍3

मेरा भी यही विचार है! हम Vuejs के साथ टाइपस्क्रिप्ट का उपयोग कर रहे हैं और हमारी इकाई परीक्षण फाइलें एक परीक्षण निर्देशिका में नहीं बल्कि घटक स्रोत कोड के साथ हर जगह हैं।

vidal7 11 जन॰ 2019

इस सुविधा को देखना अच्छा लगेगा, हम वर्तमान में थोड़ा विस्की सेटअप का उपयोग कर रहे हैं जिसके परिणामस्वरूप बनाम कोड विभिन्न लाइनिंग त्रुटियों को हाइलाइट करता है जो इस मुद्दे को हल करने के लिए हमारी कमांड लाइन लिंट हाइलाइट करता है।

JimBeem 29 जन॰ 2019

मुझे अत्यधिक संदेह है कि यह सुविधा कभी भी लागू की जाएगी, tslint को सामान्य रूप से सक्रिय रूप से बनाए रखा नहीं जा रहा है। मेरा सुझाव है कि @typescript-eslint स्विच करें, इसे एस्लिंट और टीएस दोनों परियोजनाओं से पूर्ण समर्थन मिला और माइग्रेट करना पहले से कहीं अधिक आसान है @typescript-eslint/eslint-plugin-tslint । और tslint और संबंधित एस्लिंट नियम/अन्य विकल्प उपलब्ध के साथ एक कॉम्पेट टेबल है। एस्लिंट सेटअप अत्यधिक अनुकूलन योग्य है, इसलिए मुझे tslint से चिपके रहने का कोई मतलब नहीं दिखता।

infctr 29 जन॰ 2019

👍1

मैं .gitIgnore... में फ़ाइलों के लिए tsLint नियमों के लिए git रिपॉजिटरी उपयोग की अवधारणा को लागू करने का प्रस्ताव करता हूं। किसी विशेष उपनिर्देशिका को पंक्तिबद्ध करते समय, एक ओवरराइड फ़ाइल के साथ, लिंटर के संदर्भ के रूप में आपकी वर्तमान पदानुक्रम स्थिति का उपयोग। फिर आप अपनी इच्छानुसार किसी भी निर्देशिका स्तर पर किसी भी कॉन्फ़िगरेशन को शामिल या बहिष्कृत कर सकते हैं।

जैसे
एक tslint कॉन्फ़िगरेशन रूट में रखा गया है, और आपके स्रोत कोड संरचना में किसी विशेष स्तर पर, आप एक अलग व्यवहार चाहते हैं, बस उस उपनिर्देशिका की जड़ में एक्सटेंशन tslint फ़ाइल के साथ इसे ओवरराइड करें।

redevill 8 फ़र॰ 2019

@redevil यह लोगों को test फ़ोल्डर में परीक्षण लिखने में मदद करता है। लेकिन घटक/सेवा के एक ही फ़ोल्डर में something.test.ts रूप में एक लेखन परीक्षण नहीं।

VincentLanglet 8 फ़र॰ 2019

👍3

सहमत - लेकिन मामूली बदलाव के साथ: (जिसे टेम्पलेट जनरेटर (सीएलआई स्टाइल) के साथ स्वचालित किया जा सकता है)
MyComponentDir
--- MyComponentTestsDir
------tslint.test.json
------कुछ.टेस्ट.ts
---mycomponent.component.css
---mycomponent.component.html
---mycomponent.component.ts

विचार अभी भी काम कर सकता है।

redevill 8 फ़र॰ 2019

👎6

इस प्रस्ताव के बहुत बड़े प्रशंसक। हाँ कृपया! मेरी प्राथमिकता ओवरराइड्स कॉन्सेप्ट होगी।

matthewcorven 15 मार्च 2019

बीटीडब्ल्यू, tslint की पदावनति घोषणा को देखते हुए, मैं _really_ कल्पना नहीं कर सकता कि इस स्तर पर इतना बड़ा परिवर्तन किया जाएगा, और मेरी टीम एस्लिंट की ओर बढ़ रही है, जिसमें पहले से ही प्रति-नियम + प्रति-फ़ाइल ओवरराइड सुविधाएं हैं।

RoystonS 15 मार्च 2019

👍1

उपरोक्त घोषणा: https://medium.com/palantir/tslint-in-2019-1a144c2317a9

DanielSchaffer 15 मार्च 2019

@RoystonS मूल रूप से सही है, इस बिंदु पर tslint में इतनी बड़ी सुविधा नहीं जोड़ी जाएगी। देखें #4534