हम DevTools टीम में TypeScript के बहुत बड़े प्रशंसक हैं. इतना ही नहीं, DevTools में नया कोड इसी में लिखा जा रहा है. साथ ही, हम पूरे कोडबेस को TypeScript की टाइप-चेकिंग के लिए माइग्रेट कर रहे हैं. इस माइग्रेशन के बारे में ज़्यादा जानने के लिए, Chrome Dev Summit 2020 में हमारी बातचीत देखें. इसलिए, Puppeteer के कोडबेस को TypeScript में माइग्रेट करना भी सही था.
माइग्रेशन की योजना बनाना
माइग्रेट करने का तरीका तय करते समय, हमने छोटे कदमों में आगे बढ़ने का फ़ैसला लिया. इससे माइग्रेशन का ओवरहेड कम रहता है. साथ ही, किसी भी समय कोड के सिर्फ़ छोटे हिस्से पर काम किया जा रहा होता है. इससे जोखिम भी कम रहता है. अगर किसी चरण में कोई गड़बड़ी होती है, तो उसे आसानी से पहले जैसा किया जा सकता है. Puppeteer का इस्तेमाल बहुत से लोग करते हैं. अगर इसकी रिलीज़ में कोई गड़बड़ी होती है, तो उनमें से कई लोगों को समस्याएं हो सकती हैं. इसलिए, यह ज़रूरी था कि हम बदलावों से जुड़े जोखिम को कम से कम रखें.
हमें यह भी फ़ायदा हुआ कि Puppeteer में यूनिट टेस्ट का एक बेहतरीन सेट मौजूद है, जो इसकी सभी सुविधाओं को कवर करता है. इसका मतलब है कि हमें भरोसा था कि माइग्रेशन के दौरान, कोड में कोई गड़बड़ी नहीं हुई. साथ ही, हम अपने एपीआई में भी कोई बदलाव नहीं कर रहे थे. माइग्रेशन का मकसद यह था कि इसे Puppeteer के किसी भी उपयोगकर्ता को यह पता चलने से पहले पूरा कर लिया जाए कि हमने माइग्रेट कर लिया है. टेस्ट, इस रणनीति का अहम हिस्सा थे. अगर हमारे पास टेस्ट कवरेज नहीं होती, तो हम माइग्रेशन की प्रोसेस जारी रखने से पहले उसे जोड़ देते.
टेस्ट किए बिना कोड में कोई बदलाव करना जोखिम भरा होता है. हालांकि, पूरी फ़ाइलों या पूरे कोडबेस में बदलाव करना, खास तौर पर जोखिम भरा होता है. मशीनरी में बदलाव करते समय, कोई चरण छूट जाना आम बात है. कई बार, टेस्ट में ऐसी समस्या का पता चला है जो लागू करने वाले और समीक्षक, दोनों को छूट गई थी.
हमने शुरुआत में कंटिन्यूअस इंटिग्रेशन (सीआई) सेटअप पर समय बिताया. हमें पता चला है कि Pull Request के लिए सीआई (कंट्रोल इंटिग्रेशन) की प्रोसेस अक्सर काम नहीं करती थी और अक्सर फ़ेल हो जाती थी. ऐसा अक्सर होता था कि हम अपने सीआई को अनदेखा कर देते थे और किसी भी तरह से, पुश अनुरोधों को मर्ज कर देते थे. ऐसा इसलिए, क्योंकि हम मानते थे कि Puppeteer में कोई समस्या नहीं है, बल्कि सीआई में एक बार की गई कोई गड़बड़ी है.
कुछ सामान्य रखरखाव और नियमित टेस्ट फ़्लेक को ठीक करने के लिए खास समय देने के बाद, हम इसे लगातार पास होने की स्थिति में ले आए. इससे हमें सीआई को सुनने और यह जानने में मदद मिली कि कोई गड़बड़ी होने पर, असल समस्या का पता चलता है. यह काम आसान नहीं है. साथ ही, सीआई के बार-बार चलने को देखकर परेशानी होती है. हालांकि, माइग्रेशन के दौरान मिलने वाले पुल अनुरोधों की संख्या को देखते हुए, यह ज़रूरी था कि हमारा टेस्ट सुइट भरोसेमंद तरीके से काम करता रहे.
एक फ़ाइल चुनना और उसे लैंड करना
इस समय, हमारा माइग्रेशन पूरा हो चुका था. साथ ही, हमारे पास एक बेहतरीन सीआई सर्वर था, जिसमें कई टेस्ट मौजूद थे. हमने किसी भी फ़ाइल को चुनने के बजाय, माइग्रेट करने के लिए जान-बूझकर एक छोटी फ़ाइल चुनी. यह एक काम का तरीका है, क्योंकि इससे आपको अपनी प्लान की गई प्रोसेस की पुष्टि करने में मदद मिलती है. अगर यह इस फ़ाइल पर काम करता है, तो इसका मतलब है कि आपका तरीका सही है. अगर नहीं, तो आपको फिर से शुरुआत करनी होगी.
इसके अलावा, फ़ाइल के हिसाब से बदलाव करने से (और Puppeteer के नियमित रिलीज़ के साथ, ताकि सभी बदलाव एक ही npm वर्शन में न भेजे जाएं) जोखिम कम हो गया. हमने पहली फ़ाइल के तौर पर DeviceDescriptors.js को चुना, क्योंकि यह कोडबेस में सबसे आसान फ़ाइलों में से एक थी. ऐसा हो सकता है कि इतना सारा काम करने के बाद, आपको ऐसा लगे कि आपने बहुत कम बदलाव किया है. हालांकि, हमारा मकसद एक साथ बहुत ज़्यादा बदलाव करना नहीं है. हमें धीरे-धीरे और सावधानी से, एक-एक फ़ाइल में बदलाव करना है. इस तरीके की पुष्टि करने में लगने वाला समय, माइग्रेशन के दौरान ज़्यादा मुश्किल फ़ाइलों को माइग्रेट करने में ज़रूर बचता है.
पैटर्न की पुष्टि करना और उसे दोहराना
शुक्र है कि DeviceDescriptors.js में बदलाव करके, उसे कोडबेस में शामिल कर लिया गया. साथ ही, प्लान ठीक वैसा ही काम कर रहा है जैसी हमें उम्मीद थी! इस समय, आपके पास हमने जो किया वही करने का विकल्प है. GitHub लेबल का इस्तेमाल करके, सभी पुल रिक्वेस्ट को एक साथ ग्रुप किया जा सकता है. हमें यह तरीका, प्रोग्रेस को ट्रैक करने के लिए काफ़ी मददगार लगा.
इसे माइग्रेट करें और बाद में बेहतर बनाएं
किसी भी JavaScript फ़ाइल के लिए, हमारी प्रोसेस यह थी:
- फ़ाइल का नाम
.jsसे.tsपर बदलें. - TypeScript कंपाइलर को चालू करें.
- किसी भी समस्या को ठीक करें.
- पुल का अनुरोध बनाएं.
शुरुआती पुल रिक्वेस्ट में ज़्यादातर काम, मौजूदा डेटा स्ट्रक्चर के लिए TypeScript इंटरफ़ेस निकालने का था. DeviceDescriptors.js को माइग्रेट करने वाले पहले पुल अनुरोध के मामले में, कोड इस तरह बदला:
module.exports = [
{
name: 'Pixel 4',
… // Other fields omitted to save space
},
…
]
और यह हो गया:
interface Device {
name: string,
…
}
const devices: Device[] = [{name: 'Pixel 4', …}, …]
module.exports = devices;
इस प्रोसेस के तहत, हमने कोडबेस की हर लाइन की जांच की है. किसी भी कोडबेस में, कुछ सालों में कई बदलाव हो जाते हैं. ऐसे में, कोड को फिर से लिखकर उसमें सुधार किया जा सकता है. खास तौर पर, TypeScript पर माइग्रेट करने के बाद, हमें कुछ ऐसी जगहें मिलीं जहां कोड को थोड़ा रीस्ट्रक्चर करने से, कंपाइलर का ज़्यादा फ़ायदा लिया जा सकता था और टाइप सेफ़्टी को बेहतर बनाया जा सकता था.
हालांकि, तुरंत ये बदलाव न करें. माइग्रेशन का मकसद, कोडबेस को TypeScript में ले जाना है. बड़े माइग्रेशन के दौरान, आपको हमेशा यह सोचना चाहिए कि इससे सॉफ़्टवेयर और आपके उपयोगकर्ताओं को कोई नुकसान तो नहीं पहुंचेगा. शुरुआती बदलावों को कम रखकर, हमने इस जोखिम को कम किया है. फ़ाइल को मर्ज करने और TypeScript में माइग्रेट करने के बाद, हम टाइप सिस्टम का फ़ायदा पाने के लिए, कोड को बेहतर बनाने के लिए फ़ॉलो-अप बदलाव कर सकते थे. पक्का करें कि आपने माइग्रेशन के लिए तय समयसीमा सेट की हो और उसमें ही काम किया हो.
टाइप डेफ़िनिशन की जांच करने के लिए, टेस्ट को माइग्रेट करना
पूरे सोर्स कोड को TypeScript पर माइग्रेट करने के बाद, हम अपने टेस्ट पर फ़ोकस कर पाए. हमारे टेस्ट में कई चीज़ों की जांच की गई थी, लेकिन सभी टेस्ट JavaScript में लिखे गए थे. इसका मतलब है कि उन्होंने टाइप की परिभाषाओं की जांच नहीं की थी. इस प्रोजेक्ट का एक लंबे समय से चल रहा लक्ष्य (जिस पर हम अभी भी काम कर रहे हैं) है कि Puppeteer के साथ, अच्छी क्वालिटी वाली टाइप डेफ़िनिशन को बिना किसी बदलाव के इस्तेमाल किया जा सके. हालांकि, हमारे कोडबेस में टाइप डेफ़िनिशन के बारे में कोई जांच नहीं थी.
टेस्ट को TypeScript में माइग्रेट करने पर (एक ही प्रोसेस का पालन करके, फ़ाइल के हिसाब से), हमें TypeScript में ऐसी समस्याएं मिलीं जिन्हें उपयोगकर्ताओं को ढूंढना पड़ता. अब हमारे टेस्ट में न सिर्फ़ सभी फ़ंक्शन शामिल हैं, बल्कि ये हमारे TypeScript की क्वालिटी की जांच भी करते हैं!
Puppeteer के कोडबेस पर काम करने वाले इंजीनियर के तौर पर, हमें TypeScript से पहले से ही काफ़ी फ़ायदा हुआ है. बेहतर सीआई एनवायरमेंट के साथ-साथ, Puppeteer पर काम करते समय हमें ज़्यादा बेहतर नतीजे मिले. साथ ही, TypeScript की मदद से ऐसे गड़बड़ियों का पता चला जो npm रिलीज़ में शामिल हो सकती थीं. हमें खुशी है कि हम अच्छी क्वालिटी वाली TypeScript डेफ़िनिशन उपलब्ध करा रहे हैं. इससे Puppeteer का इस्तेमाल करने वाले सभी डेवलपर को भी फ़ायदा मिलेगा.
झलक वाले चैनल डाउनलोड करना
Chrome कैनरी, डेवलपर या बीटा को अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर इस्तेमाल करें. इन झलक वाले चैनलों की मदद से, आपको DevTools की नई सुविधाओं का ऐक्सेस मिलता है. साथ ही, इनसे आपको वेब प्लैटफ़ॉर्म के सबसे नए एपीआई की जांच करने में मदद मिलती है. इसके अलावा, इनकी मदद से उपयोगकर्ताओं से पहले ही अपनी साइट पर समस्याओं का पता लगाया जा सकता है!
Chrome DevTools की टीम से संपर्क करना
DevTools से जुड़ी नई सुविधाओं, अपडेट या किसी भी अन्य चीज़ के बारे में चर्चा करने के लिए, यहां दिए गए विकल्पों का इस्तेमाल करें.
- crbug.com पर जाकर, हमें सुझाव/राय दें या शिकायत करें. साथ ही, किसी सुविधा का अनुरोध करें.
- DevTools में ज़्यादा विकल्प > सहायता > DevTools से जुड़ी समस्या की शिकायत करें का इस्तेमाल करके, DevTools से जुड़ी समस्या की शिकायत करें.
- @ChromeDevTools पर ट्वीट करें.
- DevTools के YouTube वीडियो में नया क्या है या DevTools के बारे में सलाह देने वाले YouTube वीडियो पर टिप्पणियां करें.