घोड़ा मर चुका है - रोना: tslint से eslint में संक्रमण

कुछ समय पहले तक, सामने की सभी परियोजनाओं में, डोडो पिज्जा इंजीनियरिंग के डेवलपर्स ने tslint का उपयोग किया था - एक उपयोगी उपकरण जो बताता है कि आपने कोड को गड़बड़ कर दिया था, गलतियाँ की, एक शैली में कोड बनाए रखने और कई टिप्पणियों को सही करने में मदद करता है। लेकिन तब tslint लिया और मर गया। कटौती के तहत, मैं आपको बताता हूं कि ऐसा क्यों हुआ, मृतक पर आंसू बहाना कैसे रोकें और एस्लिंट टूल पर स्विच करें, और कुछ बहुत ही अंतरंग भी दिखाएं।



वास्तव में, यह सब बहुत पहले शुरू हुआ था: आखिरी टसलिन कर्नेल रिलीज़ 2016 में पहले से ही था। और यही वह क्षण होता है जब "अंतिम" कहने का समय शुरू होता है, अगर कोई तब भी "अंतिम" कहे, क्योंकि वह रिलीज़ वास्तव में अंतिम था। 19 फरवरी, 2019 को, tslint के विकास को रोकने के लिए एक आधिकारिक पोस्ट जारी किया गया था। इसमें, विकास कंपनी (वैसे, यह माइक्रोसॉफ्ट भी नहीं है) दृढ़ता से सभी को एस्लिंट पर स्विच करने की सलाह देती है, क्योंकि उनके प्रयासों का उद्देश्य अब इस लिंटर में टाइपस्क्रिप्ट समर्थन में सुधार करना होगा।

एक भाषा, एक ढेर, एक समुदाय

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

अगर यह सिर्फ चाहते थे तो Microsoft खुद नहीं होगा। हम उनके सॉफ्टवेयर की गुणवत्ता के बारे में जो भी कहते हैं, वे महान विकास उपकरण (और, वैसे, इनपुट डिवाइस) करते हैं। इसलिए इस बार वे खाली हाथ नहीं आए, बल्कि एक प्रवास योजना लिखी। इस योजना के अनुसार, 1 अगस्त, 2019 को tslint नियमों का विकास पहले ही बंद कर दिया गया है, और tslint का विकास 1 नवंबर, 2019 को समाप्त हो जाएगा। हालांकि, ईमानदार होने के लिए, विकास को बहुत पहले बंद कर दिया गया है (नवीनतम रिलीज के लिए ऊपर देखें)।

यहाँ यह पाठक के लिए स्पष्ट हो जाना चाहिए कि यह एस्लिंट पर स्विच करने का समय है, कोई अन्य विकल्प नहीं है। गोली को मीठा करने के लिए, यह कहने योग्य है कि:

• जबकि tslint टाइपस्क्रिप्ट और सिंटैक्स चेकिंग के सही उपयोग पर अधिक जोर देने के साथ टाइपस्क्रिप्ट पर केंद्रित है, एस्केंट रिएक्ट घटकों के सिंटैक्स सहित, सामने वाले सभी चीज़ों को कवर करता है;
• एस्लिंट में बहुत अधिक पूर्वनिर्धारित नियम हैं;
• ऐसे नियम (और प्लगइन्स) हैं जो ब्लॉक स्तर पर कोड की जांच करते हैं (कोड दोहराव, कथित जटिलता, आदि);
• ऐसे प्लगइन्स हैं जो कोड की बिल्कुल भी जांच नहीं करते हैं, लेकिन, उदाहरण के लिए, नियमित अभिव्यक्ति।

सामान्य तौर पर, यह एक नए लिंटर को संक्रमण की तरह दिखता है, जो एक मुख्यधारा का उत्पाद है, जो हमारे लिए पहले से अनदेखे अवसरों की एक पूरी दुनिया खोल देगा। अच्छा, चलो कोशिश करते हैं!

प्रोजेक्ट में एस्लिन्ट जोड़ें

मैं नीचे नियमों के प्रवास के बारे में बात करूंगा। इस बीच, एस्लेंट के साथ काम करने के लिए एक परियोजना स्थापित करें।
यदि आपके पास पहले से ही tslint के साथ एक परियोजना है, तो पहले tslint से संबंधित सभी पैकेजों को हटा दें: tslint ही, tslint-reaction, tslint-config-prettier, आदि।

अब इस परियोजना में एस्लिंट पैकेज जोड़ें (सब कुछ निर्भरता के रूप में सेट करें):

• अपने आप को बढ़ाता है;
• @ टाइपस्क्रिप्ट-एसलिंट / पार्सर - टाइपस्क्रिप्ट को पार्स करने के लिए इंजन;
• @ टाइपस्क्रिप्ट-एस्लिंट / एस्लिंट-प्लगइन - टाइपस्क्रिप्ट के लिए नियम सेट

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 सेक्शन आपके प्रोजेक्ट विकल्पों के बारे में बताता है। मेरे उदाहरण में, यह ब्राउज़र के लिए एक परियोजना है (यानी कोड ब्राउज़र में काम करेगा)। नोड.जेएस के लिए लिखें - नोड निर्धारित करें: सच। निम्नलिखित दो विकल्प जेएस की बोली का परीक्षण करने का संकेत देते हैं। सामान्य तौर पर, हम टाइपस्क्रिप्ट के लिए कोड की जांच करेंगे, लेकिन यदि आपकी परियोजना में जेएस के लिए भी कोड है, तो उन्हें कसने के लिए मत भूलना। खुद के लिए, हमने तय किया कि हम इन मापदंडों को tsconfig.json में लक्ष्य के समान मान देते हैं।

मानक एस्लिंट नियम सेट के बारे में कुछ भी विवादास्पद नहीं है, जैसे कि अभिव्यक्ति या रिक्त स्थान / टैब के अंत में आवश्यक अर्धविराम। सभी नियम विशिष्ट रूप से उपयोगी हैं। आप देख सकते हैं कि कौन से नियम और किस स्तर पर यहाँ शामिल हैं ।

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

फिर आपको टाइप बैग से अनुशंसित नियमों को एक अलग बैग में जोड़ना चाहिए। यहां आपको यह ध्यान रखना होगा कि सामान्य वाक्यविन्यास नियम (जैसे var पर प्रतिबंध लगाना) उसी तरह काम करेंगे।

लेकिन नियमों के लिए जो टीएस प्रकार का उपयोग करते हैं (उदाहरण के लिए, @ टाइपस्क्रिप्ट-एस्लिंट / नो-अनावश्यक-टाइप-एसेरेशन), टाइपस्क्रिप्ट इंजन की आवश्यकता है। और इंजन को tsconfig.json फ़ाइल की आवश्यकता होगी, जिस पथ को निर्दिष्ट किया जाना चाहिए।

Tsconfig.json में, हम डोडो पिज्जा इंजीनियरिंग में आमतौर पर बहिष्कृत निर्दिष्ट करते हैं और परीक्षण बाहर फेंकते हैं ताकि वे परियोजना के साथ निर्माण न करें। लेकिन काम करने के लिए, आपको निर्दिष्ट और शामिल करना होगा। यही है, सभी फाइलें जिन्हें लिंट करने की आवश्यकता है उन्हें स्पष्ट रूप से परियोजना में शामिल किया जाना चाहिए। इसके बिना, यह पता लगाने वाली प्रत्येक फ़ाइल पर शपथ ग्रहण होगा: "फ़ाइल परियोजना में नहीं है, मुझे कुछ भी नहीं करना है, मैं त्रुटियों का एक गुच्छा नहीं फेंकूंगा।" प्रोजेक्ट फ़ाइलों को स्पष्ट रूप से निर्दिष्ट किए बिना एक विकल्प है - createDefaultProgram: true पैरामीटर। यह, संक्षेप में, का अर्थ है: "जो आप पाते हैं वह सब पारसी है।" लेकिन डेवलपर्स प्रदर्शन में महत्वपूर्ण गिरावट के कारण ऐसा करने के खिलाफ दृढ़ता से सलाह देते हैं।

यदि आप टाइपस्क्रिप्ट फ़ाइलों को संसाधित करने के लिए ForkTsCheckerWebpackPlugin का उपयोग करते हैं, तो tslint: true प्रतिस्थापित tslint: true eslint: true साथ eslint: true इसके मापदंडों में eslint: true (webpack.config.ts में)।

यह कमांड लाइन से लिंटर के लॉन्च को स्थापित करने के लायक भी है। इससे पहले, इस मान को स्क्रिप्ट खंड में package.json :

 "eslint": "eslint --cache --ext .js,.jsx,.ts,.tsx src", "eslint:dump": "eslint --print-config ./.eslintrc.json", 

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

इस विकल्प में, एस्लेंट पहले से ही परियोजना में काम करेगा और यहां तक ​​कि कुछ जाम भी पकड़ सकता है: ग्लोबल्स, अप्रयुक्त सारणी आदि को फिर से परिभाषित करना।

Visual Studio कोड सेट करना

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

स्टूडियो (dbaeumer.vscode-eslint) के लिए एक एस्क्लिंट प्लगइन है, इसे स्थापित करने की आवश्यकता है। उसके बाद, कुछ भी वैसे भी काम नहीं करेगा, कुछ भी जोर नहीं दिया जाएगा और सही किया जाएगा। क्यों? क्योंकि प्लगइन में एक कॉन्फ़िगरेशन है, जो कहता है कि आपको केवल जावास्क्रिप्ट फ़ाइलों में काम करने की आवश्यकता है।

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

 "eslint.validate": [ "javascript", "javascriptreact", "typescriptreact", "typescript", ], 

उसके बाद, स्टूडियो को पुनरारंभ करें और सब कुछ अंत में काम करना शुरू कर देगा।

अब यह नियमों को कॉन्फ़िगर करने के लिए बना हुआ है

परियोजना स्थापित है। अब नियमों के बारे में, क्योंकि नियमों की सूची के ऊपर उदाहरण में रिक्त था।

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

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

हमने तय किया कि हमारे पास जो भी tslint नियम सेट हैं, उन्हें माइग्रेट नहीं करना है। और खरोंच से अपना खुद का सेट बनाएं।

एस्लिंट के लिए पूर्वनिर्धारित नियम सेट हैं:

• ESLint अनुशंसित नियमों का एक तटस्थ सेट है जो होलीवरों को नहीं करने के विचार के साथ बनाया गया है। केवल स्पष्ट रूप से आवश्यक चेक शामिल हैं: अप्रयुक्त चर, आदि। सभी बाद के सेट इस एक का विस्तार करते हैं।
• Google - होलीवर के लिए पहले से ही एक कारण है: इंडेंटेशन के लिए कड़ाई से रिक्त स्थान हैं, एक अर्धविराम की आवश्यकता है।
• AirBnB - एक अनिवार्य अर्धविराम सहित सख्त शैली के नियम भी हैं।
• स्टैंडआर्ट - अर्धविराम यहां निषिद्ध हैं, लेकिन अनुगामी अल्पविराम भी निषिद्ध हैं।

हमें कोई भी तैयार पैकेज पसंद नहीं आया। यह अजीब लग सकता है, लेकिन स्टाइलिस्टिक युद्धों से बचने के लिए हमारे लिए एक नए लिंटर को स्विच करना महत्वपूर्ण है। यदि हम हर जगह इस तरह लिखते हैं (अर्धविराम के बिना टैब, ट्रेलिंग कॉमा अनिवार्य हैं), तो इसे ऐसा ही रहने दें - मुख्य बात यह है कि यह सभी परियोजनाओं में समान है।

वादा किया गया सेक्स: नियमों का अपना सेट

ईमानदारी से, आपके एस्लिंट नियम को दिखाने के लिए एक लड़की जैसे स्तन दिखा रही है: और कोई रहस्य नहीं हैं। मैंने लंबे समय तक सोचा कि क्या यह ऐसा करने लायक है। लेकिन, साथी लड़कियों के साथ परामर्श करने के बाद, मैंने फैसला किया कि यह इसके लायक था।

मैं उन प्लगइन्स से शुरू करूँगा जिनका हम उपयोग करते हैं:

• प्रतिक्रिया - प्रतिक्रिया घटक कोड के लिए जाँच करता है। नियमों का मूल सेट प्लस हमारा। महत्वपूर्ण से: हम शुद्ध कार्यात्मक घटकों के लिए डूब गए;
• प्रतिक्रिया-हुक - प्रतिक्रिया डेवलपर्स से हुक के उपयोग के बारे में नियम;
• वादा - वादा करते समय सामान्य त्रुटियों के लिए जाँच। यह टाइपस्क्रिप्ट कोड के साथ थोड़ा अजीब काम करता है। महत्वपूर्ण से: हम हर जगह वादा का उपयोग करने की कोशिश करते हैं और कॉलबैक का उपयोग नहीं करते हैं और फिर कोड की बेहतर पठनीयता के कारण पकड़ लेते हैं;
• ऑप्टिमाइज़-रेगेक्स एक मजेदार प्लगइन है जो नियमित अभिव्यक्ति को बेहतर बनाने के लिए सुझाव देता है। बहुत उपयोगी नहीं है, क्योंकि regexp हमारे पास थोड़ा है। लेकिन सभी से दूर regexp जादू है। तो यह उपयोगी है, लेकिन बहुत पूछने वाला नहीं है;
• सोनारज एक फायर-प्लगइन है जिसमें कोड जटिलता और विशिष्ट रीफैक्टरिंग त्रुटियों के लिए चेक हैं। पहली एक मज़ेदार बात है: प्लगइन कोड की कथित जटिलता का मूल्यांकन करता है और सलाह देता है जब यह कोड को सरल बनाने के लायक है। त्रुटियों को दूर करने के लिए खोज अक्सर कोड को सरल बनाने या कम से कम, पठनीयता में सुधार करने की अनुमति देता है;
• @ टाइपस्क्रिप्ट-एस्लिंट - टाइपस्क्रिप्ट कोड की जाँच के लिए नियम नियम। और बुनियादी नियमों को अक्षम करने के लिए एक सेट जो टीएस के साथ संगत नहीं है।

हमारी पूरी नियम फ़ाइल यहाँ है । मैं ध्यान देता हूं कि यह एक हठधर्मिता नहीं है और इसे अपडेट किया जाता है क्योंकि यह परियोजनाओं के लिए अनुकूल है।