@adidahiya @nchen63 द्वारा यह टिप्पणी देखें।

@nchen63 से :

यह टैब को ठीक करता है -> x रिक्त स्थान और x रिक्त स्थान -> टैब, लेकिन x रिक्त स्थान को ठीक नहीं करता -> y रिक्त स्थान

हालांकि यह x spaces से y spaces ।

मेरी परियोजना 2 और 4 रिक्त स्थान दोनों का उपयोग करती है। फिक्स नियम x spaces से y spaces बहुत उपयोगी होगा।

मैं भी इस मुद्दे में भाग गया, यह उम्मीद कर रहा था कि यह आकार के उल्लंघन को ठीक करेगा, या कम से कम उन्हें त्रुटियों के रूप में रिपोर्ट करेगा ताकि मैं उन्हें ठीक कर सकूं। फिलहाल ऐसा लगता है कि साइट पर प्रलेखित इंडेंट आकार के लिए कॉन्फ़िगरेशन (https://palantir.github.io/tslint/rules/indent/) वास्तव में कुछ भी नहीं करता है।

हाँ, कृपया इस बग को ठीक करें। एंगुलर सीएलआई फ़ाइल या प्रोजेक्ट बनाते समय इंडेंटेशन स्तर के लिए 2 रिक्त स्थान का उपयोग करता है, और सभी उद्धरण सिंगल कोट्स हैं। फिर यह उपयोगकर्ता के tslint.json के अनुसार इन्हें ठीक करने के लिए tslint चलाता है। उद्धरण अच्छी तरह से काम करते हैं (मेरी पसंद के अनुसार दोहरे उद्धरण चिह्नों में बदलना), लेकिन इंडेंटेशन 2 रिक्त स्थान पर रहता है (जबकि मैं 4 पसंद करता हूं)। Tslint केवल एक त्रुटि की रिपोर्ट करता है यदि वह एक वास्तविक TAB वर्ण देखता है, लेकिन उचित लगता है कि उसे रिक्त स्थान की संख्या की भी जाँच करनी चाहिए

मुझे ऐसा लगता है कि https://github.com/palantir/tslint/blob/master/src/rules/indentRule.ts में इस्तेमाल किया जा रहा कार्यान्वयन काफी अनुभवहीन है, और मैं इसे x spaces -> y spaces । यहां टिप्पणी के आधार पर दृष्टिकोण टैब के साथ ठीक प्रतीत होता है, लेकिन मैं इस दृष्टिकोण को रिक्त स्थान के लिए व्यवहार्य नहीं देख सकता।

कहें, उदाहरण के लिए, 2 रिक्त स्थान की इंडेंटेशन चौड़ाई चुनी गई थी, और इस कोड पर विचार करें:

foo = {
    a: {
  b: {
    c: 'c'
  }
    },
    d: 'd'
}

हमारे वर्तमान कार्यान्वयन को यह बिल्कुल विफल करने के बारे में कैसे पता चलेगा? रिक्त स्थान का प्रत्येक क्रम रेगेक्स / / । यहां तक ​​कि अगर हम 2 रिक्त स्थान के गुणकों की तलाश करते हैं, तो यह बीत जाएगा। इसी तरह, बहु-स्तरीय इंडेंटेशन परिदृश्यों में, 4 प्रमुख रिक्त स्थान एक गुजरने वाला परिदृश्य हो सकता है, जबकि 4 रिक्त स्थान के साथ एकल स्तर के इंडेंटेशन की शुरुआत विफल होनी चाहिए।

मुझे लगता है कि किसी भी समाधान को एएसटी को पार करने की आवश्यकता होगी, जैसा कि एस्लिंट करता है (https://github.com/eslint/eslint/blob/master/lib/rules/indent.js)। इसका नकारात्मक पक्ष यह होगा कि हम tabs -> spaces या spaces -> tabs लिए थोड़ा सा प्रदर्शन हिट लेंगे। हम सेटिंग्स के आधार पर कार्यान्वयन को चुनकर इसे प्राप्त कर सकते हैं, लेकिन मैं अनुमान लगाता हूं कि यदि टैब और रिक्त स्थान के संयोजन का उपयोग किया जाता है, तो वर्तमान कार्यान्वयन विफल हो जाएगा, इस मामले में हमें केवल एएसटी-आधारित समाधान का उपयोग करना चाहिए।

मुझे लगता है कि एस्लिंट कार्यान्वयन में किए गए कम से कम कुछ एएसटी कार्य टाइपस्क्रिप्ट की लाइब्रेरी द्वारा सीधे नियंत्रित किए जा सकते हैं, इसलिए समाधान लिखना बहुत कठिन नहीं होना चाहिए।

हमारे वर्तमान कार्यान्वयन को यह बिल्कुल विफल करने के बारे में कैसे पता चलेगा?

इसकी _तकनीकी रूप से_ आवश्यकता नहीं है। align नियम आपको इस तरह कोड लिखने से रोकेगा। ज़रूर, हम indent नियम में भी AST पर चल सकते हैं। मुझे केवल इस बात की परवाह है कि indent और align कुछ संयोजन मुझे वह पूरा करने की अनुमति देते हैं जो मैंने मुद्दे के विवरण में लिखा था।

संरेखण नियम आपको इस तरह कोड लिखने से रोकेगा।

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

मैं एक ही समस्या का सामना कर रहा हूँ। नीचे दिया गया नियम रिक्त स्थान के बजाय उपयोग किए जा रहे टैब को पकड़ लेगा, लेकिन रिक्त स्थान की गलत संख्या नहीं पकड़ेगा। मैं 2 को किसी अन्य संख्या में बदल सकता हूं, और मुझे अभी भी कोई त्रुटि नहीं मिलती है। मैं tslint 5.5.0 का उपयोग कर रहा हूँ।

"indent": [true, "spaces", 2],

इस पर कोई अपडेट? (यदि कोई पहले से किसी सुधार पर काम नहीं कर रहा है, तो मैं इसे आज़माने के लिए तैयार हूँ।)

@mDibyo इसके लिए जाएं

@mDibyo क्या आपने इस पर कोई प्रगति की है?

मेरे पास आंशिक कार्यान्वयन है। इसे पूरा करने की कोशिश करेंगे और सप्ताहांत में पीआर करेंगे

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

दूसरी ओर, Prettier हर पंक्ति में सबसे अधिक कोड फिट करने का प्रयास करता है।

क्या होगा यदि आप ऐसा नहीं चाहते हैं?

प्रिंट की चौड़ाई 120 पर सेट होने के साथ, प्रीटियर अत्यधिक कॉम्पैक्ट, या अन्यथा अवांछनीय कोड उत्पन्न कर सकता है।

हम अपनी परियोजनाओं में 120 वर्णों का उपयोग करते हैं।

इसके अलावा, यह अभी तक एक और निर्भरता है। मुझे लगता है कि मैं केवल नियमित TSLint नियमों का उपयोग करना पसंद करूंगा।

मुझे लगता है कि मैं केवल नियमित TSLint नियमों का उपयोग करना पसंद करूंगा।

@ ग्लेन -84 हाँ, यह ठीक है, इसलिए मैं यह नहीं कह रहा हूँ कि हमें TSLint से सभी स्वरूपण नियमों को हटा देना चाहिए और पूरी तरह से बाहरी फॉर्मेटर को सौंपना चाहिए। Prettier स्पष्ट रूप से रायशुमारी है और हर कोई इसका उपयोग करने के लिए चुनने वाला नहीं है। यह मुद्दा अभी भी पीआर के लिए खुला है।

इस मुद्दे के साथ क्या हो रहा है?

मेरा जनसंपर्क प्रगति पर काम कर रहा है, कई मामलों में, अभी भी समय चाहिए। @cyberhck

इसलिए हम उम्मीद करते हैं कि यह जल्द ही विलय हो जाएगा: थोड़ा_स्माइलिंग_फेस:

यहां कोई अपडेट?

शायद हम टाइपस्क्रिप्ट-फॉर्मेटर अनुरक्षकों से कुछ एपीआई का पर्दाफाश करने के लिए कह सकते हैं? पैकेज पहले से ही सत्यापित कर सकता है कि एक संपूर्ण स्रोत फ़ाइल tslint.json फ़ाइल में सेटिंग्स के अनुसार स्वरूपित है

हालांकि, TSLint के फिक्सर सेटअप के साथ अच्छा खेलने के लिए इसे मदद की आवश्यकता हो सकती है।

समस्या यह प्रतीत होती है कि विफलता केवल तभी रिपोर्ट की जाती है जब गलत व्हाइटस्पेस वर्ण का उपयोग किया जाता है, न कि इंडेंट आकार बंद होने पर।

यदि गलत इंडेंटेशन वर्ण का उपयोग किया जाता है, तो @adidahiya मैं इसे किसी त्रुटि की रिपोर्ट करने के लिए नहीं प्राप्त कर सकता। अगर मैं नियम को रिक्त स्थान/4 पर सेट करता हूं और कुछ ऐसा है:

export function foo() {
return 123;
}

या

export function foo() {
<tab>return 123;
}

यह एक त्रुटि वापस रिपोर्ट नहीं करता है। आपकी मूल टिप्पणी के अनुसार, क्या आप वाकई इसकी रिपोर्ट करते हैं यदि यह गलत व्हाइटस्पेस वर्ण है?

इस पर कोई अग्रिम? बस पूछ रहा हूँ

सलाह? सुंदर का प्रयोग करें।

क्या किसी ने tslint-eslint-नियमों की कोशिश की

@jscharett tslint-eslint-rules ter-indent नियम के साथ काम करता है। दुर्भाग्य से इसमें JSX इंडेंटेशन शामिल नहीं है ...

यहां ठीक होने की कोई उम्मीद है?

यह बग अभी भी v5.10.0 . में ठीक नहीं किया गया है

मुझे कहना होगा, मुझे नहीं लगता कि TSLint कभी भी JS कोड के साथ-साथ Prettier को प्रारूपित करने में सक्षम होगा। यह एक जटिल समस्या है, और प्रीटियर ने इसे किसी और से बेहतर तरीके से हल किया है। मुझे नहीं लगता कि हमें इसके लिए TSLint पर भरोसा करना चाहिए, खासकर जब से परियोजनाएं अक्सर दोनों उपकरणों का उपयोग करती हैं, और संघर्ष की संभावना पैदा होगी ...

संपादित करें: _how_ के बेहतर विचार के लिए यह समस्या जटिल है, इस पीआर की समीक्षा

@aervin मैं यहाँ असहमत हूँ। मेरी राय में, 2 परियोजनाओं के अलग-अलग उद्देश्य हैं। Prettier स्वरूपण की श्रेणी में आता है जबकि TSLint सत्यापन के अनुरूप अधिक है। हां, TSLint कुछ नियमों के लिए स्वरूपण कर सकता है, लेकिन एक लिंटर के रूप में इसके इच्छित उद्देश्य, सत्यापन के लिए वापस जाते हैं।

Prettier पर भरोसा करने के साथ समस्या यह है कि यह राय है। यह बहुत अच्छा है कि आप इसकी शैली से सहमत हैं, लेकिन यदि आप नहीं करते हैं तो क्या होगा? हम सभी JSLint का उपयोग करते थे, और हम सभी ने शिकायत की थी क्योंकि यह इतना राय वाला था। फिर JSHint और JSCS आए, जिससे हमें कुछ नियंत्रण मिला। अब हमारे पास @eslint जैसे शक्तिशाली उपकरण हैं जो हमें प्लग-एन-प्ले और स्वचालित रूप से "ठीक" करने की क्षमता प्रदान करते हैं।

जबकि मुझे यकीन है कि प्रीटीयर एक महान परियोजना है, मैं व्यक्तिगत रूप से इसे एक कदम पीछे की ओर देखता हूं। इसका नियंत्रण मुझसे दूर ले जा रहा है। TSLint को कोड को "ठीक" करने की आवश्यकता नहीं है, यदि यह समस्या है, तो बस इसे एक समस्या के रूप में फ़्लैग करें। मुझे संदेह नहीं है कि यह मुद्दा जटिल है, लेकिन एस्लिंट ने इसे हल किया। नियम काम करता था; इसे तोड़ने के लिए क्या बदला?

@jscharett आपकी अनुकूल प्रतिक्रिया के लिए धन्यवाद। मैं सहमत हूं कि इन परियोजनाओं के अलग-अलग उद्देश्य हैं, या _चाहिए_ हैं। मेरा तर्क है कि हमें इन परियोजनाओं को उन्हीं उद्देश्यों तक सीमित रखना चाहिए। आइए प्रीटियर को इंडेंटेशन समस्याओं को ठीक करने के लिए छोड़ दें, और टीएसलिंट को तीर कार्यों के बारे में चेतावनी देने वाले देवों को छोड़ दें जिन्हें सरल बनाया जा सकता है।

मैं इस बात से भी सहमत हूं कि प्रीटियर की राय है। मैं इसके बजाय प्रीटीयर के बारे में पसंद करता हूं। अब मेरी टीम को यह चर्चा करने की आवश्यकता नहीं है कि किसकी स्वरूपण राय अधिक उचित है। हम सभी प्रीटियर के बारे में शिकायत कर सकते हैं: हंसना:।

संपादित करें:

नियम काम करता था; इसे तोड़ने के लिए क्या बदला?

शुरुआती अंक की टिप्पणी मुझे विश्वास दिलाती है कि यह नियम कभी भी इरादा के अनुसार काम नहीं कर रहा था।

जबकि मुझे यकीन है कि प्रीटीयर एक महान परियोजना है, मैं व्यक्तिगत रूप से इसे एक कदम पीछे की ओर देखता हूं। इसका नियंत्रण मुझसे दूर ले जा रहा है।

मेरा अनुभव यह था कि मैंने सोचा था कि जब तक मैंने प्रीटीयर को जोड़ा, तब तक मुझे फॉर्मेटिंग नियमों पर ठीक-ठाक नियंत्रण रखने की परवाह थी ... और जल्द ही मुझे एहसास हुआ कि मुझे चीजों को प्रारूपित करने के विशेष तरीके के बारे में इतना परवाह नहीं है, क्योंकि तथ्य यह है कि वे लगातार स्वरूपित थे। यह एक बहुत बड़ा संज्ञानात्मक भार है कि अब इसके बारे में चिंता न करें, और पूरी तरह से इस बात पर ध्यान केंद्रित करें कि मैं कोड को _do_ कैसे चाहता हूं, इसके बजाय यह कैसा दिखता है।

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

कम चर्चा, और अधिक PR'ing की जरूरत है। 😉😉

आगे बढ़ो @ffxsam

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

@ffxsam क्योंकि इस बारे में बहस है कि क्या tslint ts भाग के बारे में अधिक है या लिंट भाग के बारे में है

यह एक वैध बिंदु है। ऐसा लगता है कि TSLint/ESLint के साथ कुछ ओवरलैप है। लेकिन तथ्य यह है कि एक गैर-काम करने वाला indent विकल्प है जो कि कौन जानता है कि कब तक टूट गया है। ऐसा लगता है कि टीएसलिंट कोडबेस से परिचित किसी व्यक्ति के लिए इसे ठीक करने के लिए सबसे तेज़/आसान चीज होगी ...?

x spaces => y spaces को ठीक करने के लिए वोट करें। यह एक ऐसी सुविधा है जिस पर हमारी कंपनी बहुत अधिक निर्भर करती है। इसे ठीक न करने का कोई मतलब नहीं है।

@ffxsam मैं इस मुद्दे को लगभग एक साल से देख रहा हूं, हाँ यह लंबा हो गया है, लेकिन जैसा कि आप देख सकते हैं कि दो पीआर प्रयास हैं, और यह अब तक काम नहीं कर रहा है, मुझे लगता है कि यह जितना दिखता है उससे कहीं अधिक कठिन है, लेकिन अनुरक्षकों के लिए यह आसान हो सकता है, मेरे पास बस बहुत धैर्य है: थोड़ा_मुस्कुराते हुए_फेस:

अभी भी खाली परियोजना में प्रतिलिपि प्रस्तुत करने योग्य
https://github.com/dimaShin/tslint-reproduce-2814

हाय @dimaShin , एक प्रतिलिपि प्रस्तुत करने योग्य भंडार बनाने के लिए समय निकालने के लिए धन्यवाद। हालाँकि टीम इस मुद्दे से पहले से ही अवगत है, पुनरुत्पादन कभी कोई समस्या नहीं थी।

हम इस सुविधा का इंतजार कर रहे हैं, संभवत: फिक्स विकल्प के साथ, लेकिन यह मेरे लिए कोई समस्या नहीं है। पिछली बार मैंने जाँच की थी कि लोग इंडेंटेशन की जाँच करने के लिए और बाकी सभी चीज़ों के लिए tslint का उपयोग कर रहे हैं।

मैं यह नहीं कह रहा हूं कि यह आपके लिए अच्छा होगा, मेरे लिए यह निश्चित रूप से नहीं है, मैं इस विशेष विकल्प के लिए .editorconfig का उपयोग करने का भी सुझाव दूंगा और इसे हल होने पर बाद में tslint पर स्विच कर दूंगा।

दोबारा, अधिक जानकारी जोड़ने के लिए समय निकालने के लिए धन्यवाद :)

आइए इंडेंटेशन की जाँच के लिए एक रणनीति निर्धारित करें। संदर्भ के लिए, एस्लिंट द्वारा उपयोग की जाने वाली रणनीति यहां दी गई है:

1. एक ऑफ़सेटस्टोरेज इंस्टेंस वांछित ऑफ़सेट का नक्शा संग्रहीत करता है, जहां प्रत्येक टोकन में किसी अन्य निर्दिष्ट टोकन या पहले कॉलम से निर्दिष्ट ऑफ़सेट होता है।
2. जैसे ही एएसटी का पता लगाया जाता है, टोकन के वांछित ऑफसेट को तदनुसार संशोधित करें। उदाहरण के लिए, ब्लॉकस्टेटमेंट में प्रवेश करते समय, ब्लॉकस्टेटमेंट में सभी टोकन को ब्लॉकस्टेटमेंट के शुरुआती घुंघराले ब्रेस से 1 इंडेंट स्तर से ऑफसेट करें।
3. एएसटी को पार करने के बाद, ऑफसेटस्टोरेज कंटेनर के अनुसार प्रत्येक टोकन के अपेक्षित इंडेंटेशन स्तरों की गणना करें।
4. प्रत्येक पंक्ति के लिए, फ़ाइल में वास्तविक इंडेंटेशन के लिए पहले टोकन के अपेक्षित इंडेंटेशन की तुलना करें, और यदि दो मान समान नहीं हैं, तो टोकन की रिपोर्ट करें।

यह रणनीति वाक्य रचना पर आधारित है, जो पिछली टिप्पणियों के आधार पर बहुत अधिक राय वाली है क्योंकि इसके लिए एक निश्चित तरीके से लाइनों को तोड़ने की आवश्यकता होती है। मैं इंडेंटेशन की जांच करने का एक आसान तरीका प्रस्तावित करता हूं जो इस बात से स्वतंत्र है कि कोड को लाइनों में कैसे तोड़ा जाता है:

1. इंडेंटेशन की इकाई को सेटिंग्स में परिभाषित किया गया है। टैब के लिए, यह एक टैब वर्ण है। रिक्त स्थान के लिए, यह दो या चार अंतरिक्ष वर्ण हैं।
2. फ़ाइल की पहली गैर-रिक्त पंक्ति में इंडेंटेशन की शून्य इकाइयाँ होनी चाहिए
3. प्रत्येक बाद की गैर-रिक्त पंक्ति में या तो होना चाहिए
   ए। इंडेंटेशन की इकाइयों की समान संख्या पूर्ववर्ती गैर-रिक्त रेखा के रूप में या
   बी। पूर्ववर्ती गैर-रिक्त रेखा के रूप में इंडेंटेशन की इकाइयों की संख्या से कम या
   सी। पूर्ववर्ती गैर-रिक्त पंक्ति के रूप में इंडेंटेशन की इकाइयों की संख्या से बिल्कुल एक अधिक

चर्चा के लिए कुछ अतिरिक्त बातें:

• आकार पैरामीटर का टैब के साथ कोई प्रभाव नहीं पड़ता है (क्यों?)
• कोई कारण नहीं है कि size पैरामीटर कोई धनात्मक पूर्णांक नहीं हो सकता
• इंडेंटेशन आकार को ऑटो-फिक्सिंग शायद सिंटैक्स रणनीति मार्ग के बिना लागू नहीं किया जा सकता है

@stifflerus भी नियम {} ब्लॉक के बिना/के लिए/तीर फ़ंक्शन के साथ काम करना चाहिए

@maximelkin क्या आपके द्वारा दिए गए उदाहरण दूसरी पंक्ति पर इंडेंट नहीं हैं? क्या आप इसका उदाहरण दे सकते हैं कि प्रस्तावित रणनीति कहाँ विफल होगी?

if(this) that(); //okay because it's all one line

if(this)
  that(); //also okay because the second line is indented

let x = () => f(); //okay because it's all one line

let y = () =>
  f(); // I have not seen any code but like this but it would be okay

बढ़िया होगा अगर यह तय किया गया था।

मुझे विश्वास नहीं हो रहा है कि कुछ मौलिक है क्योंकि इंडेंटेशन नियम लागू करना अभी भी काम नहीं कर रहा है।

तो, 2018 में ऐसे ts-code को लिंट करने का कोई तरीका नहीं है?

const x = {
  a: 1,
   b: 2,
}

मेरे लिये कार्य करता है
./.eslintrc.ts.js :

module.exports = {
  'parser': 'typescript-eslint-parser',
  'parserOptions': {
    'ecmaVersion': 6,
    'sourceType': 'module',
    'ecmaFeatures': {
      'jsx': true,
    }
  },
  'plugins': [
    'react',
  ],
  'rules': {
    'indent': ['error', 2],
  },
}

yarn eslint --no-eslintrc --config ./.eslintrc.ts.js --ext .tsx src

https://github.com/eslint/typescript-eslint-parser

कोणीय में इंडेंट समस्या के लिए मुझे जो समाधान मिला वह अगले चरणों के साथ सुंदर जोड़ना है:
npm स्थापित करें --save-dev tslint-plugin-prettier सुंदर tslint-चमेली-नियम
tslint.json संपादित करें ->
` "नियम निर्देशिका": [
"नोड_मॉड्यूल/कोडलीज़र",
"नोड_मॉड्यूल्स/tslint-प्लगइन-प्रीटियर",
"नोड_मॉड्यूल/tslint-चमेली-नियम/जिला"

],
"विस्तारित": "tslint-plugin-prettier",

"नियम": {
"सुंदर": सच,
// यहां अपने वांछित नियम जोड़ें `

और package.json में जोड़ें ->
","सुंदर": {
"एकल उद्धरण": सच है,
"प्रिंटविड्थ": 140,
"अर्ध": सच है,
"ब्रैकेटस्पेसिंग": सच,
"एरोपेरेंस": "हमेशा",
"पार्सर": "टाइपस्क्रिप्ट"
}"

यह एक ऐसी कार्यक्षमता है जिसका उपयोग लगभग हर कोई दैनिक आधार पर करता है। अगर इस मुद्दे पर अधिक ध्यान दिया जाए तो मैं आभारी रहूंगा।

दोस्तों, आप tslint-eslint-rules द्वारा प्रदान किए गए ter-indent विकल्प का उपयोग कर सकते हैं।

"टेर-इंडेंट": [सच, ४, {"स्विचकेस": १ }]

इसने मेरे लिए काम किया। चीयर्स!

@hiteshaleriya कुछ समय के लिए मैंने अपने प्रोजेक्ट में यही किया है, लेकिन यह वास्तव में त्रुटियों को ठीक नहीं कर रहा है, बस उन्हें चुप tslint.json :

{
    "extends": "tslint-config-airbnb",
    "rules": {
        "ter-indent": ["error", "spaces", 4],
        "no-unused-vars": ["warn"],
        "no-multi-spaces": false,
        "no-console": false,
        "max-line-length": false,
        "import-name": false
    }
}

और यहां एक प्रासंगिक उदाहरण दिया गया है जो चेतावनियां या त्रुटियां पैदा किए बिना समाप्त हो गया:

function retrieveAndSetConfig(): Promise<any> {
  return new Promise((resolve, _) => {
  // ^ 2 spaces, expected 4
    const ghe = new GHEUtils();
    // ^ 4 spaces, expected 8
    // ...
}

टैब का उपयोग करते समय यह त्रुटियां भी नहीं दिखा रहा है (हालांकि यह डिज़ाइन द्वारा हो सकता है जब 4 रिक्त स्थान मौजूद हों?)

@SpencerKaiser क्या आप कृपया नीचे दिखाए अनुसार अपना टेर-इंडेंट नियम अपडेट कर सकते हैं और फिर कोशिश करें:

"ter-indent": [true, 4]

मैंने आपके उदाहरण की कोशिश की और यह मेरे अंत में अपेक्षित काम कर रहा है (त्रुटियों के कारण)।

@hiteshaleriya इतनी जल्दी मेरे पास वापस --fix । कोई विचार?

@SpencerKaiser क्या आप --fix कमांड को दो बार चलाने का प्रयास कर सकते हैं। पहली बार यह पहली पंक्ति को इंडेंट करेगा, फिर दूसरी बार यह बाकी को इंडेंट करेगा (आपके उदाहरण कोड के लिए)। अजीब लगता है, लेकिन अगर यह काम नहीं करता है तो कृपया समस्या की रिपोर्ट करें।

@hiteshaleriya तो कुछ अवलोकन ... मुझे इसे फिर से चलाने की आवश्यकता नहीं थी, मुझे इसे लगभग n/4 बार चलाने की आवश्यकता थी जहां n रिक्त स्थान में इंडेंटेशन की लंबाई है प्रोजेक्ट में सबसे दूर की इंडेंट लाइन ¯\_(ツ)_/

अंत में उन सभी को खत्म करने के बाद, ऐसा लगता है कि यह इस तरह की बुनियादी इंडेंटेशन त्रुटियों को छोड़ रहा है:

class Something {
    function myFunc() {
        const myThing = {
            wat: 1,
         wattt: 5,    // 9 spaces, expected 12
        };
    }
}

अगर मैं const (पंक्ति 17) से 0 रिक्त स्थान के इंडेंटेशन स्तर को गड़बड़ कर देता हूं, तो जब मैं --fix छोड़ता हूं, तो बाकी को त्रुटियों के साथ चिह्नित किया जाता है।

ERROR: 17:1  ter-indent  Expected indentation of 8 spaces but found 0.
ERROR: 18:1  ter-indent  Expected indentation of 4 spaces but found 12.
ERROR: 20:1  ter-indent  Expected indentation of 0 spaces but found 8.

--fix , यहां पहला पास दिया गया है:

        const myThing = {
    wat: 1,
         wattt: 5,
};

और दूसरा पास:

        const myThing = {
            wat: 1,
         wattt: 5,
        };

विचार ??

मैंने उस समस्या को tslint-config-prettier . के साथ कैसे हल किया है

@shubich मैं वही काम कर रहा था ...

क्या इस पर कोई अपडेट है?

@MaKCbIMKo जहां तक ​​मैं समझता हूं, पूरी टीम एस्लिंट विज़िट टाइपस्क्रिप्ट-एस्लिंट को एकीकृत करने के लिए आगे बढ़ रही है, और निकट भविष्य में tslint को पदावनत कर दिया जाएगा, इसलिए यह अभी के लिए इस नियम को अनदेखा करने जितना अच्छा है (या tslint-config-prettier का उपयोग करें) )

इस कार्य की जटिलता और परियोजना की दिशा में परिवर्तन के कारण समापन: #4534

टाइपस्क्रिप्ट-एसलिंट से ESLint नियम मेरे लिए पूरी तरह से काम करता है (देखें #4534):

module.exports = {
    "env": {
        "browser": true,
    },
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaVersion": 2019,
        "sourceType": "module",
        "ecmaFeatures": {
            "jsx": true
        },
        "project": "./tsconfig.json",
    },
    "plugins": ["@typescript-eslint"],
    "rules": {
        "@typescript-eslint/indent": ["error", 2] // or ["error", "tab"]
    }
}

मैंने उस समस्या को tslint-config-prettier . के साथ कैसे हल किया है

लिंक नहीं मिला।

बीप बूप! TSLint पदावनत है और आपको typescript-eslint पर स्विच करना चाहिए! 🤖

आगे अनावश्यक चर्चाओं को रोकने के लिए इस मुद्दे को लॉक किया जा रहा है। शुक्रिया! 👋

PS tslint-config-prettier - कृपया _linters_ जैसे TSLint से _format_ अपने टाइपस्क्रिप्ट का उपयोग बंद करें। यह _formatter_ जैसे