यह पोस्ट ब्लॉग पोस्ट की एक सीरीज़ का हिस्सा है. इसमें, DevTools के आर्किटेक्चर में किए जा रहे बदलावों और उसे बनाने के तरीके के बारे में बताया है.
JavaScript मॉड्यूल में माइग्रेशन और वेब कॉम्पोनेंट पर माइग्रेशन के बाद, हम Devtools के आर्किटेक्चर में किए जा रहे बदलावों और इसके बनाने के तरीके पर हमारी ब्लॉग पोस्ट सीरीज़ जारी रख रहे हैं. (अगर आपने इसे पहले नहीं देखा है, तो हमने DevTools के आर्किटेक्चर को आधुनिक वेब पर अपग्रेड करने के अपने काम पर एक वीडियो पोस्ट किया है. इसमें आपके वेब प्रोजेक्ट को बेहतर बनाने के लिए 14 सलाह दी गई हैं.)
इस पोस्ट में, हम Closure Compiler टाइप चेकर से TypeScript में स्विच करने के अपने 13 महीने के सफ़र के बारे में बताएंगे.
शुरुआती जानकारी
DevTools कोड बेस के साइज़ और इस पर काम करने वाले इंजीनियर का भरोसा बनाए रखने के लिए, टाइप चेकर का इस्तेमाल करना ज़रूरी है. इसे ध्यान में रखते हुए, साल 2013 में DevTool ने बंद करने के कंपाइलर का इस्तेमाल शुरू किया. बंद करने की प्रक्रिया का इस्तेमाल करके DevTools में बदलाव करने में मदद करने वाले इंजीनियर, भरोसे के साथ बदलाव कर पाएंगे. क्लोज़र कंपाइलर, अलग-अलग तरह की जांच करेगा, ताकि यह पक्का किया जा सके कि सभी सिस्टम इंटिग्रेशन सही तरीके से टाइप किए गए हैं.
हालांकि, समय बीतने के साथ आधुनिक वेब डेवलपमेंट में वैकल्पिक टाइप चेकर लोकप्रिय होने लगे. इसके दो अहम उदाहरण हैं TypeScript और Flow. इसके अलावा, TypeScript Google में एक आधिकारिक प्रोग्रामिंग भाषा बन गया है. हालांकि, इस तरह के नए चेकर की लोकप्रियता बढ़ी है, लेकिन हमने यह भी देखा कि हम शिपिंग रिग्रेशन से जुड़े ऐसे रिग्रेशन का पता लगा रहे हैं जिन्हें किसी टाइप चेकर की मदद से रोक लिया जाना चाहिए. इसलिए, हमने टाइप चेकर के चुने गए विकल्प का फिर से आकलन करने और DevTools को डेवलप करने के अगले चरणों का पता लगाने का फ़ैसला किया है.
टाइप चेकर का आकलन करना
DevTools पहले से ही टाइप चेकर का इस्तेमाल कर रहा था. इसलिए, हमारे लिए इस सवाल का जवाब देना था:
क्या हम क्लोजर कंपाइलर का इस्तेमाल जारी रखते हैं या किसी नए टाइप के चेकर पर माइग्रेट करते हैं?
इस सवाल का जवाब देने के लिए, हमें कई विशेषताओं के आधार पर टाइप चेकर का आकलन करना पड़ा. टाइप चेकर का इस्तेमाल करते समय, हम इंजीनियर के भरोसे को ध्यान में रखते हैं, इसलिए हमारे लिए सबसे ज़रूरी पहलू है टाइपिंग का सही होना. दूसरे शब्दों में: असल समस्याओं का पता लगाने में, टाइप चेकर कितना भरोसेमंद होता है?
हमारे आकलन में, भेजे गए रिग्रेशन को ध्यान में रखा गया और यह भी पता लगाया गया कि उनकी असल वजहें क्या होंगी. यहां एक अनुमान यह है कि बंद करने वाले कंपाइलर का इस्तेमाल पहले से ही किया जा रहा था. इसलिए, Close में इन समस्याओं का पता नहीं चलता. इसलिए, हमें यह तय करना होगा कि कोई अन्य टाइप चेकर ऐसा कर सकता है या नहीं.
TypeScript में टाइप सहीता
क्योंकि TypeScript, Google में आधिकारिक तौर पर काम करने वाली प्रोग्रामिंग भाषा थी और तेज़ी से बढ़ती जा रही है. इसलिए, हमने पहले TypeScript का आकलन करने का फ़ैसला लिया. TypeScript एक दिलचस्प विकल्प था, क्योंकि TypeScript टीम DevTools का इस्तेमाल अपने टेस्ट प्रोजेक्ट में से एक के तौर पर करती है. इसकी मदद से, यह ट्रैक किया जाता है कि डेवलपर, JavaScript टाइप की जांच करने के साथ काम करता है या नहीं. उनके बेसलाइन रेफ़रंस टेस्ट आउटपुट से पता चला था कि TypeScript बड़ी संख्या में तरह की समस्याओं का पता लगा रहा है - ऐसी समस्याएं जिनका पता, Close कंपाइलर को नहीं मिल पा रहा था. इनमें से कई समस्याएं, रिग्रेशन की मुख्य वजह हो सकती थीं, जिन्हें हम शिपिंग कर रहे थे. इससे हमें यह भरोसा हुआ कि TypeScript, DevTools के लिए एक कारगर विकल्प हो सकता है.
JavaScript मॉड्यूल पर माइग्रेट करने के दौरान, हमें पता चला था कि Close कंपाइलर में पहले की तुलना में ज़्यादा समस्याएं सामने आ रही हैं. मानक मॉड्यूल फ़ॉर्मैट पर जाने से Close पर हमारे कोड बेस को समझने की क्षमता बढ़ गई. इससे टाइप चेकर्स का असर भी बढ़ गया. हालांकि, TypeScript टीम DevTools के बेसलाइन वर्शन का इस्तेमाल कर रही है, जो JavaScript मॉड्यूल के माइग्रेशन से पहले का था. इसलिए, हमें यह पता लगाना पड़ा कि क्या JavaScript मॉड्यूल में माइग्रेशन होने से, TypeScript कंपाइलर के ज़रिए मिलने वाली गड़बड़ियों की संख्या कम हुई है या नहीं.
TypeScript का मूल्यांकन करना
DevTools कई दशकों से मौजूद है, जिसमें यह काफ़ी बड़ा हो गया है और कई सुविधाओं वाला वेब ऐप्लिकेशन बन गया है. इस ब्लॉग पोस्ट को लिखते समय, DevTools में पहले-पक्ष के JavaScript कोड की करीब 1,50,000 लाइनें शामिल हैं. जब हमने अपने सोर्स कोड पर TypeScript कंपाइलर चलाया, तो बड़ी संख्या में गड़बड़ियां मिलने लगीं. हम यह पता लगा पाए कि जब TypeScript कंपाइलर, कोड रिज़ॉल्यूशन से जुड़ी कम गड़बड़ियां (~2,000 गड़बड़ियां) अपना रहा था, तब भी टाइप के साथ काम करने से जुड़ी हमारे कोड बेस में 6,000 और गड़बड़ियां थीं.
इससे पता चला कि TypeScript टाइप को ठीक करने की प्रक्रिया को समझ रहा था, लेकिन इसे हमारे कोड बेस में बड़ी संख्या में टाइप की गड़बड़ियां मिली.
इन गड़बड़ियों के मैन्युअल तौर पर किए गए विश्लेषण से पता चला था कि टाइपस्क्रिप्ट (ज़्यादातर मामलों में) सही थी.
TypeScript इनकी पहचान कर पाया और Close में वजह नहीं थी, क्योंकि अक्सर Close कंपाइलर के ज़रिए किसी टाइप का अनुमान Any लगाया जाता है, जबकि टाइपस्क्रिप्ट असाइनमेंट के आधार पर टाइप का अनुमान लगाती है और ज़्यादा सटीक टाइप का अनुमान लगाती है.
इसलिए, TypeScript ने हमारे ऑब्जेक्ट के स्ट्रक्चर को बेहतर तरीके से समझकर, उसका इस्तेमाल करने में गड़बड़ी का पता लगाया.
इसके बारे में एक ज़रूरी बात यह है कि DevTools में बंद करने के कंपाइलर के इस्तेमाल में, @unrestricted को बार-बार इस्तेमाल किया जाता है.
@unrestricted के साथ किसी क्लास के बारे में जानकारी देने से, उस क्लास के लिए बंद करने के कंपाइलर की प्रॉपर्टी की सख्त जांच बंद हो जाती है. इसका मतलब है कि कोई डेवलपर, टाइप सुरक्षा के बिना भी क्लास की परिभाषा को बेहतर बना सकता है.
हमें इस बारे में कोई ऐतिहासिक जानकारी नहीं मिली कि DevTools कोडबेस में @unrestricted का इस्तेमाल सबसे ज़्यादा क्यों था. हालांकि, इसकी वजह से कोड बेस के बड़े हिस्सों के लिए, बंद करने के टूल को कम सुरक्षित मोड में चलाया गया.
टाइपस्क्रिप्ट के ज़रिए मिली गड़बड़ियों के साथ हमारे रिग्रेशन के क्रॉस-विश्लेषण में एक ओवरलैप भी दिखाया गया. इसकी वजह से हमें लगा कि TypeScript इन समस्याओं को रोक सकता है (बशर्ते वे टाइप सही हों).
any कॉल किया जा रहा है
इस बिंदु पर, हमें अपने Close कंपाइलर के इस्तेमाल को बेहतर बनाने या TypeScript पर माइग्रेट करने में से किसी एक का फ़ैसला लेना था. (Google या Chromium में, यह सुविधा काम नहीं करती थी. इसलिए, हमें यह विकल्प छोड़ना पड़ा.) JavaScript/TypeScript टूलिंग पर काम करने वाले Google इंजीनियरों से, हमारी बातचीत और सुझावों के आधार पर, हमने TypeScript कंपाइलर चुनने का विकल्प चुना है. (हमने हाल ही में Puppeteer को TypeScript में माइग्रेट करने के बारे में एक ब्लॉग पोस्ट भी पब्लिश की है.)
TypeScript कंपाइलर की मुख्य वजहें, बेहतर टाइपिंग का सही होना, जबकि अन्य फ़ायदों में Google में टाइपस्क्रिप्ट टीम का अंदरूनी तौर पर सपोर्ट और interfaces जैसी टाइपस्क्रिप्ट भाषा की सुविधाएं शामिल हैं (JSDoc में typedefs नहीं).
TypeScript कंपाइलर चुनने का मतलब था कि हमें DevTools कोडबेस और इसके इंटरनल आर्किटेक्चर में अच्छा-खासा निवेश करना पड़ा. हमने अनुमान लगाया कि TypeScript में माइग्रेट करने के लिए, कम से कम एक साल (साल 2020 की तीसरी तिमाही के लिए टारगेट किया गया) की ज़रूरत थी.
माइग्रेशन किया जा रहा है
सबसे बड़ा सवाल यह है कि हम TypeScript में माइग्रेट कैसे करेंगे? हमारे पास कोड की 150,000 लाइनें हैं और हम उसे एक बार में माइग्रेट नहीं कर सकते. हम यह भी जानते थे कि हमारे कोड बेस पर TypeScript चलाने से हज़ारों गड़बड़ियों का पता चल जाएगा.
हमने कई विकल्पों का आकलन किया है:
- सभी TypeScript गड़बड़ियां पाएं और उनकी तुलना "golden" आउटपुट से करें. यह तरीका TypeScript टीम के पास जैसा होगा. इस तरीके का सबसे बड़ा नुकसान यह है कि मर्ज को लेकर कई तरह के विवाद होते हैं, क्योंकि दर्जनों इंजीनियर एक ही कोडबेस में काम करते हैं.
- समस्या वाले सभी टाइप को
anyपर सेट करें. इससे TypeScript गड़बड़ियों को रोक सकेगा. हमने यह विकल्प नहीं चुना, क्योंकि माइग्रेशन के लिए हमारा लक्ष्य टाइप के हिसाब से सही होना था, जिसे दबाने की ज़रूरत नहीं है. - TypeScript की सभी गड़बड़ियों को मैन्युअल तरीके से ठीक करें. इसमें हज़ारों गड़बड़ियां ठीक की जा सकती हैं, जिनमें काफ़ी समय लगता है.
काफ़ी कोशिश के बावजूद, हमने तीसरा विकल्प चुना. इस विकल्प को चुनने की कई वजहें थीं: उदाहरण के लिए, इसकी मदद से हम सभी कोड का ऑडिट कर पाते थे. साथ ही, सभी सुविधाओं और उन्हें लागू करने के तरीके की दस साल में एक बार समीक्षा कर पाते थे. कारोबार के नज़रिए से, हम मौजूदा हालात को बरकरार रखने के बजाय, कोई नई वैल्यू नहीं दे रहे थे. इस वजह से, तीसरे विकल्प को सही विकल्प चुनना और मुश्किल हो गया.
हालांकि, TypeScript का इस्तेमाल करके हमें पूरा भरोसा था कि हम आने वाले समय में होने वाली समस्याओं को रोक सकते हैं, खास तौर पर रिग्रेशन से जुड़ी समस्याओं को. उदाहरण के लिए, "हम कारोबार की नई वैल्यू जोड़ रहे हैं" वाला तर्क कम था और "हम पक्का कर रहे हैं कि कारोबार की हासिल की गई वैल्यू को नुकसान न पहुंचे".
TypeScript कंपाइलर के लिए JavaScript का सपोर्ट
बाय-इन सुरक्षित करने और एक ही JavaScript कोड पर Close पर और टाइपस्क्रिप्ट कंपाइलर दोनों को चलाने की योजना डेवलप करने के बाद, हमने कुछ छोटी फ़ाइलों के साथ शुरुआत की. हमारा मुख्य तरीका सबसे आगे था. हम मुख्य कोड से शुरुआत करते थे और हमें आर्किटेक्चर में तब तक आगे बढ़ते जाते थे, जब तक हम ऊंचे स्तर के पैनल तक नहीं पहुंच जाते.
हमने 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 का समर्थन किया है.
नतीजों का विश्लेषण करना
हम इस तरह की इन गड़बड़ियों को ठीक करने में काफ़ी कामयाब रहे. साथ ही, टाइपस्क्रिप्ट की मदद से जांचे गए कोड की मात्रा भी धीरे-धीरे बढ़ाई. हालांकि, अगस्त 2020 में (इस माइग्रेशन के नौ महीने बाद) हमने एक चेक-इन किया और पाया कि हम अपनी मौजूदा रफ़्तार के हिसाब से समयसीमा खत्म नहीं करेंगे. हमारे एक इंजीनियर ने "TypeScriptified" (वह नाम जो हमने इस माइग्रेशन को दिया) की प्रगति दिखाने के लिए विश्लेषण ग्राफ़ बनाया है.
TypeScript माइग्रेशन की प्रोग्रेस - बचे हुए कोड की उन लाइनों को ट्रैक करना जिन्हें माइग्रेट करने की ज़रूरत है
जुलाई 2021 से दिसंबर 2021 तक का अनुमान, जो लाइन पूरी नहीं होगी. यह अनुमान हमारी समयसीमा से करीब एक साल पहले का है. प्रबंधन और अन्य इंजीनियरों से चर्चा करने के बाद, हमने टाइपस्क्रिप्ट कंपाइलर सहायता पर माइग्रेट करने वाले इंजीनियरों की संख्या बढ़ाने के लिए सहमति दी है. ऐसा इसलिए हुआ, क्योंकि हमने माइग्रेशन को साथ में चलने लायक बनाया, ताकि कई अलग-अलग फ़ाइलों पर काम करने वाले कई इंजीनियर एक-दूसरे का टकराव न करें.
इस स्थिति में, TypeScriptीकरण प्रोसेस पूरी टीम के लिए एक कोशिश बन गई. अतिरिक्त मदद की मदद से, माइग्रेट करने की प्रक्रिया को नवंबर 2020 के आखिर में पूरा किया जा सका. माइग्रेशन की प्रक्रिया शुरू होने के 13 महीने बाद, और हमारे शुरुआती अनुमान से एक साल पहले.
कुल मिलाकर, 18 इंजीनियरों की सबमिट की गई 771 बदलाव सूचियां (जो पुल के अनुरोध से मिलती-जुलती हैं) थीं. ट्रैकिंग की गड़बड़ी (https://crbug.com/1011811) में 1,200 से ज़्यादा टिप्पणियां हैं. इनमें से करीब-करीब सभी अपने-आप अपलोड हुई पोस्ट हैं, जिन्हें बदलाव सूचियों में शामिल किया गया है. हमारी ट्रैकिंग शीट में 500 से ज़्यादा पंक्तियां थीं. इन पंक्तियों में, टाइप करने की ज़रूरत वाली सभी फ़ाइलें मौजूद थीं. साथ ही, जिन फ़ाइलों को उनके लिए असाइन किया गया था उन्हें असाइन किया गया था. साथ ही, जिन बदलावों की सूची में उन्हें “टाइपस्क्रिप्टिफ़ाइड” के तौर पर रखा गया था वे भी 500 से ज़्यादा पंक्तियां थीं.
TypeScript कंपाइलर की परफ़ॉर्मेंस का असर कम करना
इस समय हमें जिस सबसे बड़ी समस्या का सामना करना पड़ रहा है, वह है TypeScript कंपाइलर की धीमी परफ़ॉर्मेंस. Chromium और DevTools बनाने वाले इंजीनियर की संख्या को देखते हुए, यह अड़चन काफ़ी महंगा है. अफ़सोस की बात यह है कि माइग्रेट करने से पहले, हम इस जोखिम का पता नहीं लगा सके. ऐसा सिर्फ़ तब हुआ, जब हमने ज़्यादातर फ़ाइलें TypeScript में माइग्रेट की थीं. इसलिए, हमने पाया कि Chromium के सभी बिल्ड में लगने वाले समय में काफ़ी बढ़ोतरी हुई है: https://crbug.com/1139220
हमने Microsoft TypeScript कंपाइलर टीम को अपस्ट्रीम में इस समस्या की रिपोर्ट की है. हालांकि, हमें अफ़सोस है कि उन्होंने इसे जान-बूझकर किया है. हमें उम्मीद है कि वे इस समस्या पर फिर से विचार करेंगे. हालांकि, हम इस समस्या को दूर करने के लिए लगातार काम कर रहे हैं, ताकि Chromium की परफ़ॉर्मेंस पर पड़ने वाले असर को कम किया जा सके.
अफ़सोस की बात यह है कि आज हमें जो समाधान मिलते हैं वे हमेशा उन लोगों के लिए सही नहीं होते जो Googler का योगदान नहीं देते. Chromium में ओपन-सोर्स के योगदान बहुत अहम हैं (खास तौर पर, Microsoft Edge की टीम के योगदान). इसलिए, हम ऐसे विकल्पों को खोज रहे हैं जो योगदान देने वाले सभी लोगों के लिए काम करें. हालांकि, इस समय हमने कोई सही वैकल्पिक समाधान नहीं ढूंढा है.
DevTools में TypeScript की मौजूदा स्थिति
इस समय, हमने अपने कोड बेस से बंद करने वाला कंपाइलर टाइप चेकर हटा दिया है और सिर्फ़ टाइपस्क्रिप्ट कंपाइलर पर भरोसा किया है. हम TypeScript-लिखाई की गई फ़ाइलें लिख सकते हैं और TypeScript की खास सुविधाओं (जैसे इंटरफ़ेस, जेनरिक वगैरह...) का इस्तेमाल कर सकते हैं. इनसे हमें हर दिन मदद मिलती है. हमें इस बात का पूरा भरोसा है कि TypeScript कंपाइलर, टाइप की गड़बड़ियों और रिग्रेशन को पकड़ लेगा. जब हम इस माइग्रेशन पर पहली बार काम शुरू करेंगे, तो हम उम्मीद करते हैं कि यह होगा. बाकी माइग्रेशन की तरह यह माइग्रेशन भी धीमा, मुश्किल, और कई बार चुनौती भरा था. हालांकि, जैसे-जैसे हमें इससे फ़ायदा मिला, हमारा मानना है कि यह सही है.
झलक दिखाने वाले चैनलों को डाउनलोड करें
अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर, Chrome के कैनरी, डेव या बीटा वर्शन का इस्तेमाल करें. झलक दिखाने वाले इन चैनलों से, आपको DevTools की नई सुविधाओं का ऐक्सेस मिलता है. साथ ही, सबसे नए वेब प्लैटफ़ॉर्म एपीआई टेस्ट करने और उपयोगकर्ताओं के ऐसा करने से पहले ही, अपनी साइट पर समस्याओं का पता लगाने में मदद मिलती है!
Chrome DevTools टीम से संपर्क करना
पोस्ट में मौजूद नई सुविधाओं और बदलावों या DevTools से जुड़ी किसी भी अन्य चीज़ के बारे में बताने के लिए, नीचे दिए गए विकल्पों का इस्तेमाल करें.
- crbug.com के ज़रिए हमें कोई सुझाव या सुझाव सबमिट करें.
- DevTools में ज़्यादा विकल्प
> सहायता > DevTools से जुड़ी समस्याओं की शिकायत करें पर जाकर, DevTools से जुड़ी समस्या की शिकायत करें. - @ChromeDevTool पर ट्वीट करें.
- DevTools YouTube वीडियो या DevTools सलाह वाले YouTube वीडियो में नया क्या है, इस बारे में टिप्पणियां करें.