यह पोस्ट, ब्लॉग पोस्ट की एक सीरीज़ का हिस्सा है. इसमें, DevTools के आर्किटेक्चर में किए जा रहे बदलावों और इसे बनाने के तरीके के बारे में बताया गया है.
JavaScript मॉड्यूल पर माइग्रेट करने और वेब कॉम्पोनेंट पर माइग्रेट करने के बाद, आज हम DevTools के आर्किटेक्चर में किए जा रहे बदलावों और इसे बनाने के तरीके के बारे में अपनी ब्लॉग पोस्ट सीरीज़ जारी रख रहे हैं. (अगर आपने अब तक नहीं देखा है, तो हमने DevTools के आर्किटेक्चर को आधुनिक वेब पर अपग्रेड करने के बारे में एक वीडियो पोस्ट किया है. इसमें, अपने वेब प्रोजेक्ट को बेहतर बनाने के 14 सुझाव दिए गए हैं.)
इस पोस्ट में, हम Closure Compiler टाइप चेकर से TypeScript पर जाने के अपने 13 महीने के सफ़र के बारे में बताएंगे.
परिचय
DevTools के कोडबेस के साइज़ और उस पर काम करने वाले इंजीनियरों को भरोसा दिलाने की ज़रूरत को देखते हुए, टाइप चेकर का इस्तेमाल करना ज़रूरी है. इस लक्ष्य को पूरा करने के लिए, DevTools ने साल 2013 में Closure Compiler का इस्तेमाल शुरू किया. Closure का इस्तेमाल करने से, DevTools के इंजीनियर भरोसे के साथ बदलाव कर पाते हैं. Closure कंपाइलर, टाइप की जांच करता है, ताकि यह पक्का किया जा सके कि सभी सिस्टम इंटिग्रेशन सही तरीके से टाइप किए गए हैं.
हालांकि, समय बीतने के साथ, आधुनिक वेब डेवलपमेंट में अन्य टाइप चेकर लोकप्रिय हो गए. TypeScript और Flow इसके दो उदाहरण हैं. इसके अलावा, TypeScript को Google की आधिकारिक प्रोग्रामिंग भाषा के तौर पर मान्यता मिली. इन नए टाइप चेकर की लोकप्रियता बढ़ने के साथ-साथ, हमें यह भी पता चला कि हम ऐसे रेग्रेशन शिप कर रहे थे जिन्हें टाइप चेकर ने पकड़ना चाहिए था. इसलिए, हमने टाइप चेकर के तौर पर अपनी पसंद का फिर से आकलन करने का फ़ैसला किया है. साथ ही, DevTools पर डेवलपमेंट के अगले चरणों के बारे में पता लगाया है.
टाइप चेकर का आकलन करना
DevTools पहले से ही टाइप चेकर का इस्तेमाल कर रहा था. इसलिए, हमें यह जवाब देना था:
क्या हमें Closure Compiler का इस्तेमाल जारी रखना चाहिए या किसी नए टाइप चेकर पर माइग्रेट करना चाहिए?
इस सवाल का जवाब देने के लिए, हमें टाइप चेकर की कई विशेषताओं का आकलन करना पड़ा. टाइप चेकर का इस्तेमाल, इंजीनियर के भरोसे पर आधारित होता है. इसलिए, हमारे लिए टाइप की सटीक जानकारी देना सबसे अहम है. दूसरे शब्दों में: टाइप चेकर, असल समस्याओं का पता लगाने में कितना भरोसेमंद है?
हमने अपने आकलन में, उन रेग्रेशन पर फ़ोकस किया जिन्हें हमने शिप किया था. साथ ही, यह भी पता लगाया कि उनकी मुख्य वजहें क्या हो सकती हैं. यहां यह माना गया है कि हम पहले से ही Closure Compiler का इस्तेमाल कर रहे थे, इसलिए Closure को ये समस्याएं नहीं मिली होंगी. इसलिए, हमें यह तय करना होगा कि क्या किसी अन्य तरह के चेकर से यह काम किया जा सकता था.
TypeScript में टाइप की सही जानकारी
TypeScript, Google पर आधिकारिक तौर पर काम करने वाली प्रोग्रामिंग लैंग्वेज थी और इसकी लोकप्रियता तेज़ी से बढ़ रही थी. इसलिए, हमने सबसे पहले TypeScript का आकलन करने का फ़ैसला लिया. TypeScript एक दिलचस्प विकल्प था, क्योंकि TypeScript टीम खुद भी DevTools का इस्तेमाल अपने टेस्ट प्रोजेक्ट के तौर पर करती है, ताकि JavaScript टाइप-चेकिंग की सुविधा के साथ अपनी काम करने की क्षमता को ट्रैक किया जा सके. उनके बेसलाइन रेफ़रंस टेस्ट आउटपुट से पता चला था कि TypeScript, टाइप से जुड़ी बहुत सारी समस्याओं का पता लगा रहा था. ये ऐसी समस्याएं थीं जिनका पता Closure कंपाइलर को ज़रूर नहीं चलता. इनमें से कई समस्याएं, शायद उन समस्याओं की मुख्य वजह थीं जो हम शिप कर रहे थे. इस वजह से, हमें लगा कि TypeScript, DevTools के लिए एक सही विकल्प हो सकता है.
JavaScript मॉड्यूल पर माइग्रेट करने के दौरान, हमें पहले से ही पता था कि Closure Compiler, पहले के मुकाबले ज़्यादा समस्याएं ढूंढ रहा है. स्टैंडर्ड मॉड्यूल फ़ॉर्मैट पर स्विच करने से, Closure को हमारे कोडबेस को समझने में मदद मिली. इससे टाइप चेकर की परफ़ॉर्मेंस भी बेहतर हुई. हालांकि, TypeScript टीम, DevTools के उस बेसलाइन वर्शन का इस्तेमाल कर रही थी जो JavaScript मॉड्यूल के माइग्रेशन से पहले का था. इसलिए, हमें यह पता लगाना था कि JavaScript मॉड्यूल पर माइग्रेट करने से, TypeScript कंपाइलर को मिलने वाली गड़बड़ियों की संख्या भी कम हुई है या नहीं.
TypeScript का आकलन करना
DevTools को एक दशक से ज़्यादा समय हो गया है. इस दौरान, यह एक बड़े और सुविधाओं से भरे वेब ऐप्लिकेशन में बदल गया है. इस ब्लॉग पोस्ट को लिखने के समय, DevTools में पहले पक्ष के JavaScript कोड की करीब 1,50,000 लाइनें थीं. जब हमने अपने सोर्स कोड पर TypeScript कंपाइलर चलाया, तो गड़बड़ियों की संख्या बहुत ज़्यादा थी. हमें पता चला है कि TypeScript कंपाइलर, कोड रिज़ॉल्यूशन से जुड़ी कम गड़बड़ियां दिखा रहा था (~2,000 गड़बड़ियां). हालांकि, हमारे कोडबेस में टाइप के साथ काम करने से जुड़ी 6,000 गड़बड़ियां अब भी मौजूद थीं.
इससे पता चला कि TypeScript, टाइप को हल करने का तरीका समझने में सक्षम था. हालांकि, उसे हमारे कोडबेस में टाइप के साथ काम करने में काफ़ी समस्याएं आ रही थीं.
इन गड़बड़ियों का मैन्युअल विश्लेषण करने से पता चला था कि ज़्यादातर मामलों में TypeScript सही था.
TypeScript ने इन गड़बड़ियों का पता लगाया, जबकि Closure ने नहीं. इसकी वजह यह है कि Closure कंपाइलर अक्सर किसी टाइप को Any मान लेता है, जबकि TypeScript असाइनमेंट के आधार पर टाइप का अनुमान लगाता है और ज़्यादा सटीक टाइप का पता लगाता है.
इसलिए, TypeScript हमारे ऑब्जेक्ट के स्ट्रक्चर को समझने में वाकई बेहतर था और उसने इस्तेमाल से जुड़ी समस्याओं का पता लगाया.
इस बात का ध्यान रखें कि DevTools में Closure कंपाइलर का इस्तेमाल करने पर, @unrestricted का बार-बार इस्तेमाल होता है.
किसी क्लास में @unrestricted का एनोटेशन जोड़ने से, उस क्लास के लिए Closure कंपाइलर की सख्त प्रॉपर्टी जांच बंद हो जाती है. इसका मतलब है कि डेवलपर, टाइप सेफ़्टी के बिना अपनी पसंद के मुताबिक क्लास की परिभाषा को बढ़ा सकता है.
हमें इस बारे में कोई जानकारी नहीं मिली कि DevTools के कोडबेस में @unrestricted का इस्तेमाल क्यों किया जाता था. हालांकि, इसकी वजह से कोडबेस के बड़े हिस्सों के लिए, Closure कंपाइलर को कम सुरक्षित मोड में चलाना पड़ता था.
TypeScript की टाइप गड़बड़ियों के साथ हमारे रेग्रेशन का क्रॉस-ऐनालिसिस करने पर भी ओवरलैप दिखे. इससे हमें लगा कि TypeScript इन समस्याओं को रोक सकता था. हालांकि, इसके लिए ज़रूरी है कि टाइप सही हों.
any कॉल करना
इस समय, हमें Closure Compiler के इस्तेमाल को बेहतर बनाने या TypeScript पर माइग्रेट करने में से किसी एक विकल्प को चुनना था. (Google या Chromium में Flow काम नहीं करता था, इसलिए हमें उस विकल्प को छोड़ना पड़ा.) JavaScript/TypeScript टूल पर काम करने वाले Google इंजीनियरों से हुई बातचीत और उनके सुझावों के आधार पर, हमने TypeScript कंपाइलर को चुना है. (हमने हाल ही में Puppeteer को TypeScript पर माइग्रेट करने के बारे में भी एक ब्लॉग पोस्ट पब्लिश की है.)
TypeScript कंपाइलर को चुनने की मुख्य वजह, टाइप की सटीक जानकारी थी. इसके अलावा, Google में TypeScript टीमों से मिलने वाली सहायता और TypeScript भाषा की सुविधाएं भी इसकी वजहें थीं. जैसे, interfaces (JSDoc में typedefs के बजाय).
TypeScript कंपाइलर चुनने का मतलब है कि हमें DevTools के कोडबेस और उसके इंटरनल आर्किटेक्चर में काफ़ी निवेश करना पड़ा. इसलिए, हमारा अनुमान है कि TypeScript पर माइग्रेट करने के लिए हमें कम से कम एक साल की ज़रूरत होगी. हमने इसे साल 2020 की तीसरी तिमाही के लिए टारगेट किया है.
माइग्रेशन की प्रोसेस
हालांकि, एक बड़ा सवाल अब भी बना हुआ है: हम TypeScript पर कैसे माइग्रेट करेंगे? हमारे पास 1,50,000 लाइन का कोड है और हम उसे एक बार में माइग्रेट नहीं कर सकते. हमें यह भी पता था कि हमारे कोडबेस पर TypeScript को चलाने से, हज़ारों गड़बड़ियां दिखेंगी.
हमने कई विकल्पों का आकलन किया:
- TypeScript की सभी गड़बड़ियां पाएं और उनकी तुलना "गोल्डन" आउटपुट से करें. यह तरीका, TypeScript टीम के तरीके से मिलता-जुलता होगा. इस तरीके का सबसे बड़ा नुकसान यह है कि मर्ज करने के दौरान अक्सर समस्याएं आती हैं. इसकी वजह यह है कि एक ही कोडबेस पर कई इंजीनियर काम करते हैं.
- समस्या वाले सभी टाइप को
anyपर सेट करें. इससे TypeScript, गड़बड़ियों को दबा देगा. हमने यह विकल्प नहीं चुना, क्योंकि माइग्रेशन का हमारा लक्ष्य, टाइप को सही करना था. इस लक्ष्य को पूरा करने में, डेटा को छिपाने से मदद नहीं मिलेगी. - TypeScript की सभी गड़बड़ियों को मैन्युअल तरीके से ठीक करें. इसके लिए, आपको हज़ारों गड़बड़ियां ठीक करनी होंगी. इसमें काफ़ी समय लगेगा.
ज़्यादा मेहनत के बावजूद, हमने तीसरे विकल्प को चुना. हमने यह विकल्प इसलिए चुना, क्योंकि इससे हमें सभी कोड का ऑडिट करने और हर 10 साल में सभी फ़ंक्शन की समीक्षा करने में मदद मिली. इसमें, फ़ंक्शन को लागू करने की समीक्षा भी शामिल है. बिज़नेस के लिहाज़ से, हम नई वैल्यू नहीं दे पा रहे थे. इसके बजाय, हम पहले जैसा ही काम कर रहे थे. इससे, तीसरे विकल्प को सही विकल्प के तौर पर बताना मुश्किल हो गया.
हालांकि, हमें पूरा भरोसा था कि TypeScript का इस्तेमाल करके, आने वाले समय में होने वाली समस्याओं को नष्ट किया जा सकता है. खास तौर पर, रेग्रेशन से जुड़ी समस्याओं को. इसलिए, "हम कारोबार में नई वैल्यू जोड़ रहे हैं" के बजाय, "हम यह पक्का कर रहे हैं कि कारोबार में पहले से मौजूद वैल्यू न खो जाए" का तर्क ज़्यादा दिया गया.
TypeScript कंपाइलर के लिए JavaScript की सहायता
एक ही JavaScript कोड पर Closure और TypeScript कंपाइलर, दोनों को चलाने का प्लान बनाने और खरीदारी की सहमति मिलने के बाद, हमने कुछ छोटी फ़ाइलों के साथ शुरुआत की. हमारा तरीका ज़्यादातर नीचे से ऊपर की ओर था: कोर कोड से शुरू करके, आर्किटेक्चर में ऊपर की ओर बढ़ते हुए, हम हाई-लेवल पैनल तक पहुंचे.
हमने DevTools में हर फ़ाइल में @ts-nocheck को पहले से जोड़कर, अपने काम को एक साथ पूरा किया. "TypeScript को ठीक करने" की प्रोसेस में, @ts-nocheck एनोटेशन को हटाना और TypeScript को मिलने वाली गड़बड़ियों को ठीक करना शामिल है. इसका मतलब है कि हमें भरोसा था कि हर फ़ाइल की जांच की जा चुकी है और ज़्यादा से ज़्यादा समस्याओं को हल कर दिया गया है.
आम तौर पर, इस तरीके से कुछ समस्याओं को ठीक किया जा सकता है. हमें TypeScript कंपाइलर में कई गड़बड़ियां मिलीं, लेकिन उनमें से ज़्यादातर गड़बड़ियां समझने में मुश्किल थीं:
anyदिखाने वाले फ़ंक्शन टाइप के साथ वैकल्पिक पैरामीटर को ज़रूरी माना जाता है: #38551- किसी क्लास के स्टैटिक तरीके के लिए प्रॉपर्टी असाइनमेंट, एलान को तोड़ता है: #38553
- बिना आर्ग्युमेंट वाले कंस्ट्रक्टर वाली सब-क्लास और आर्ग्युमेंट वाले कंस्ट्रक्टर वाली सुपर-क्लास के एलान में, चाइल्ड कंस्ट्रक्टर को छोड़ दिया जाता है: #41397
इन गड़बड़ियों से पता चलता है कि 99% मामलों में, TypeScript कंपाइलर एक मज़बूत बुनियाद है. हां, इन गड़बड़ियों की वजह से कभी-कभी DevTools में समस्याएं आ सकती हैं. हालांकि, ज़्यादातर समय ये गड़बड़ियां इतनी छोटी होती हैं कि हम उन्हें आसानी से ठीक कर लेते हैं.
.tsbuildinfo फ़ाइलों का नॉन-डेटरमिनिस्टिक आउटपुट: #37156, एक ऐसी समस्या थी जिसकी वजह से कुछ भ्रम की स्थिति पैदा हुई थी.
Chromium में, हम चाहते हैं कि एक ही Chromium कमिट के दो बिल्ड से एक ही आउटपुट मिले.
माफ़ करें, हमारे Chromium इंजीनियरों को पता चला है कि .tsbuildinfo का आउटपुट तय नहीं था: crbug.com/1054494.
इस समस्या को हल करने के लिए, हमें .tsbuildinfo फ़ाइल (जिसमें JSON होता है) में बदलाव करना पड़ा. साथ ही, डेटा का सटीक नतीजा देने के लिए, उसमें बदलाव करने के बाद उसे प्रोसेस करना पड़ा: https://crrev.com/c/2091448
अहम बात यह है कि TypeScript टीम ने अपस्ट्रीम की समस्या को हल कर दिया है. इसलिए, हमने जल्द ही इस समस्या को हल करने का तरीका हटा दिया है. गड़बड़ी की रिपोर्ट स्वीकार करने और इन समस्याओं को तुरंत ठीक करने के लिए, TypeScript टीम का धन्यवाद!
कुल मिलाकर, हमें TypeScript कंपाइलर के (टाइप) सही होने से खुशी हो रही है. हमें उम्मीद है कि बड़े ओपन-सोर्स JavaScript प्रोजेक्ट के तौर पर, Devtools ने TypeScript में JavaScript की सुविधा को बेहतर बनाने में मदद की है.
समस्या के बाद की स्थिति का विश्लेषण करना
हमने इस तरह की गड़बड़ियों को ठीक करने में काफ़ी तरक्की की है. साथ ही, TypeScript की मदद से जांचे जाने वाले कोड की संख्या को धीरे-धीरे बढ़ाया जा रहा है. हालांकि, अगस्त 2020 में (माइग्रेशन के नौ महीने बाद) हमने जांच की और हमें पता चला कि मौजूदा रफ़्तार से, हम तय समयसीमा में माइग्रेशन नहीं कर पाएंगे. हमारे एक इंजीनियर ने "TypeScriptification" (हमने इस माइग्रेशन को यह नाम दिया है) की प्रोग्रेस दिखाने के लिए, विश्लेषण का एक ग्राफ़ बनाया है.
TypeScript माइग्रेशन की प्रोग्रेस - माइग्रेट की जानी वाली कोड लाइन को ट्रैक करना
हमारा अनुमान था कि जुलाई 2021 से दिसंबर 2021 के बीच, हमारे पास कोई लाइन नहीं बचेगी. यह समयसीमा खत्म होने के करीब एक साल बाद की बात है. मैनेजमेंट और दूसरे इंजीनियरों के साथ बातचीत करने के बाद, हमने TypeScript कंपाइलर के साथ काम करने वाले इंजीनियरों की संख्या बढ़ाने पर सहमति दी है. ऐसा इसलिए किया जा सका, क्योंकि हमने माइग्रेशन को इस तरह से डिज़ाइन किया था कि एक से ज़्यादा इंजीनियर एक से ज़्यादा फ़ाइलों पर एक साथ काम कर सकें.
इस समय, TypeScript में बदलने की प्रोसेस पूरी टीम के लिए एक चुनौती बन गई. अतिरिक्त मदद से, हमने नवंबर 2020 के आखिर में माइग्रेशन पूरा कर लिया. यह माइग्रेशन शुरू होने के 13 महीने बाद हुआ. साथ ही, यह हमारे शुरुआती अनुमान से एक साल से ज़्यादा पहले हुआ.
कुल मिलाकर, 18 इंजीनियरों ने 771 बदलावों की सूचियां (पुल रिक्वेस्ट जैसी) सबमिट कीं. ट्रैकिंग बग (https://crbug.com/1011811) पर 1,200 से ज़्यादा टिप्पणियां की गई हैं. इनमें से ज़्यादातर टिप्पणियां, बदलाव सूचियों से अपने-आप पोस्ट हुई हैं. हमारी ट्रैकिंग शीट में, टाइपस्क्रिप्ट में बदली जाने वाली सभी फ़ाइलों, उन्हें असाइन करने वाले व्यक्ति, और किस चेंजलिस्ट में उन्हें “टाइपस्क्रिप्ट में बदला गया” के लिए 500 से ज़्यादा लाइनें थीं.
TypeScript कंपाइलर की परफ़ॉर्मेंस के असर को कम करना
फ़िलहाल, हमें TypeScript कंपाइलर की धीमी परफ़ॉर्मेंस से जुड़ी सबसे बड़ी समस्या का सामना करना पड़ रहा है. Chromium और DevTools बनाने वाले इंजीनियरों की संख्या को देखते हुए, यह समस्या काफ़ी महंगी है. माफ़ करें, माइग्रेशन से पहले हम इस जोखिम की पहचान नहीं कर पाए. ज़्यादातर फ़ाइलों को TypeScript में माइग्रेट करने के बाद ही, हमें पता चला कि Chromium के सभी बिल्ड में लगने वाले समय में काफ़ी बढ़ोतरी हुई है: https://crbug.com/1139220
हमने Microsoft TypeScript कंपाइलर टीम को इस समस्या की शिकायत कर दी है. हालांकि, हमें अफ़सोस है कि उन्होंने इस व्यवहार को जान-बूझकर किया गया बताया है. हमें उम्मीद है कि वे इस समस्या पर फिर से विचार करेंगे. हालांकि, इस बीच हम Chromium की परफ़ॉर्मेंस पर पड़ने वाले असर को कम करने के लिए काम कर रहे हैं.
माफ़ करें, फ़िलहाल हमारे पास जो सलूशन उपलब्ध हैं वे Google के बाहर के योगदान देने वालों के लिए हमेशा सही नहीं होते. Chromium में ओपन-सोर्स योगदान बहुत ज़रूरी हैं. खास तौर पर, Microsoft Edge की टीम के योगदान. इसलिए, हम ऐसे विकल्पों की तलाश कर रहे हैं जो सभी योगदान देने वालों के लिए काम करें. हालांकि, फ़िलहाल हमने इस समस्या का कोई दूसरा समाधान नहीं ढूंढा है.
DevTools में TypeScript की मौजूदा स्थिति
फ़िलहाल, हमने अपने कोडबेस से Closure कंपाइलर टाइप चेकर को हटा दिया है और सिर्फ़ TypeScript कंपाइलर पर भरोसा कर रहे हैं. हम TypeScript में फ़ाइलें लिख सकते हैं और TypeScript की खास सुविधाओं (जैसे, इंटरफ़ेस, जेनरिक वगैरह) का इस्तेमाल कर सकते हैं. इन सुविधाओं से हमें रोज़ काम करने में मदद मिलती है. हमें भरोसा है कि TypeScript कंपाइलर, टाइप की गड़बड़ियों और रेग्रेशन को पकड़ लेगा. जब हमने इस माइग्रेशन पर काम शुरू किया था, तब हमें यही उम्मीद थी. कई अन्य माइग्रेशन की तरह ही, यह माइग्रेशन भी धीमा, मुश्किल, और बारीकियों से भरा था. हालांकि, हमें इसके फ़ायदे मिल रहे हैं, इसलिए हमें लगता है कि यह माइग्रेशन सही था.
झलक वाले चैनल डाउनलोड करना
Chrome कैनरी, डेवलपर या बीटा को अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर इस्तेमाल करें. इन झलक वाले चैनलों की मदद से, आपको DevTools की नई सुविधाओं का ऐक्सेस मिलता है. साथ ही, इनसे आपको वेब प्लैटफ़ॉर्म के सबसे नए एपीआई की जांच करने में मदद मिलती है. इसके अलावा, इनकी मदद से उपयोगकर्ताओं से पहले अपनी साइट की समस्याओं का पता लगाया जा सकता है!
Chrome DevTools की टीम से संपर्क करना
DevTools से जुड़ी नई सुविधाओं, अपडेट या किसी भी अन्य चीज़ के बारे में चर्चा करने के लिए, यहां दिए गए विकल्पों का इस्तेमाल करें.
- crbug.com पर जाकर, हमें सुझाव/राय दें या शिकायत करें. साथ ही, किसी सुविधा का अनुरोध करें.
- DevTools में ज़्यादा विकल्प > सहायता > DevTools से जुड़ी समस्या की शिकायत करें का इस्तेमाल करके, DevTools से जुड़ी समस्या की शिकायत करें.
- @ChromeDevTools पर ट्वीट करें.
- DevTools के YouTube वीडियो में नया क्या है या DevTools के बारे में सलाह देने वाले YouTube वीडियो पर टिप्पणियां करें.