हम DevTools टीम पर TypeScript के बड़े प्रशंसक हैं. इस माइग्रेशन के बारे में ज़्यादा जानने के लिए, Chrome डेवलपर समिट 2020 में हुई हमारी बातचीत देखें. इसलिए Puppeteer के कोडबेस को TypeScript में माइग्रेट करना भी सही है.
माइग्रेशन की योजना बनाना
माइग्रेट करने का प्लान बनाते समय, हम चाहते थे कि छोटे-छोटे चरण आसानी से पूरे किए जा सकें. यह माइग्रेशन की प्रोसेस को पूरा नहीं करता. किसी भी समय, कोड के सिर्फ़ एक छोटे से हिस्से पर काम किया जाता है और इसका जोखिम भी कम रहता है. अगर इनमें से किसी एक चरण में कुछ भी गलत हो जाता है, तो आप उसे आसानी से वापस ला सकते हैं. Puppeteer के बहुत सारे उपयोगकर्ता हैं और एक टूटी हुई रिलीज़ से बहुतों के लिए समस्याएं पैदा हो सकती हैं. इसलिए, यह ज़रूरी था कि हम बदलावों के नुकसान का जोखिम कम से कम रखें.
हम इस बात से भी भाग्यशाली थे कि Puppeteer ने अपनी सभी सुविधाओं को शामिल करते हुए यूनिट टेस्ट का बेहतरीन सेट इस्तेमाल किया है. इसका मतलब है कि हमें इस बात का भरोसा था कि माइग्रेशन के दौरान हम कोड का गलत इस्तेमाल नहीं कर रहे थे. दरअसल, हम अपने एपीआई में कोई बदलाव नहीं कर रहे थे. माइग्रेशन का मकसद, किसी भी Puppeteer उपयोगकर्ता को यह महसूस किए बिना उसे पूरा करना था कि हम उसे माइग्रेट कर चुके हैं. टेस्ट उस रणनीति का अहम हिस्सा थे. अगर हमें अच्छा टेस्ट कवरेज नहीं मिला होता, तो हम माइग्रेशन जारी रखने से पहले उसे जोड़ देते.
जांच के बिना कोड में किसी भी तरह का बदलाव करना जोखिम भरा हो सकता है. हालांकि, अगर पूरी फ़ाइलों को या पूरे कोड बेस को छूने पर बदलाव किया जाता है, तो यह जोखिम भरा हो सकता है. मैकेनिकल बदलाव करते समय, एक भी चरण छूट जाना आसान है. कई बार जांच में समस्या का पता चला, जो लागू करने वाले टूल और समीक्षक, दोनों से दूर हो गया.
हमने शुरुआत में ही कंटिन्यूअस इंटिग्रेशन (सीआई) सेटअप करने में काफ़ी समय लगाया. हमने देखा कि पुल अनुरोधों के ख़िलाफ़ सीआई की प्रक्रिया में गड़बड़ी थी और अक्सर नाकामयाब होती थी. ऐसा अक्सर ऐसा होता था कि हमें अपने सीआई को अनदेखा करने और पुल अनुरोधों को मर्ज करने की आदत हो गई. हमने यह मान लिया कि यह समस्या Puppeteer में समस्या के बजाय CI के लिए सिर्फ़ एक समस्या थी.
सामान्य रखरखाव करने और कुछ सामान्य टेस्ट फ़्लेक्स को ठीक करने में लगने वाले समय के बाद, हमने इसे और भी बेहतर तरीके से पास किया. इससे हमें सीआई की बात सुनने में मदद मिली और यह भी जाना जा सकता है कि गलती एक असल समस्या की ओर इशारा कर रही है. यह काम आकर्षक नहीं है और न के बराबर सीआई को रन करते रहने से निराशा होती है, लेकिन माइग्रेशन की वजह से जितने पुल अनुरोधों को पूरा किया जा रहा था उनकी संख्या को देखते हुए, हमारे टेस्ट सुइट को भरोसेमंद तरीके से चलाना ज़रूरी था.
एक फ़ाइल चुनें और लैंड करें
ऐसा होने के बाद, हमारा माइग्रेशन पूरी तरह से तैयार था. साथ ही, एक मज़बूत सीआई सर्वर भी मौजूद था, जिसमें पूरी जांच-पड़ताल की गई थी. किसी भी आर्बिट्रेरी फ़ाइल के बारे में जानने के बजाय, हमने जान-बूझकर माइग्रेट करने के लिए एक छोटी फ़ाइल चुनी. यह एक उपयोगी अभ्यास है, क्योंकि इससे आपको उस योजना के मुताबिक बनाई गई प्रक्रिया की पुष्टि करने में मदद मिलती है, जिसे आप शुरू करने वाले हैं. अगर यह इस फ़ाइल पर काम करता है, तो आपका तरीका मान्य है; अगर ऐसा नहीं है, तो आप ड्रॉइंग बोर्ड पर वापस जा सकते हैं.
इसके अलावा, एक-एक करके फ़ाइल देने (और सामान्य Puppeteer रिलीज़ के साथ, इसलिए सभी बदलाव एक ही एनपीएम वर्शन में शिप नहीं किए जाते) से जोखिम कम रहता है. हमने DeviceDescriptors.js को पहली फ़ाइल के तौर पर चुना है, क्योंकि यह कोड बेस की सबसे आसान फ़ाइलों में से एक थी. इस तरह की सभी तैयारी और एक छोटा सा बदलाव करना थोड़ा मुश्किल महसूस हो सकता है, लेकिन हमारा मकसद तुरंत बड़े बदलाव करना नहीं है, बल्कि सावधानी से और व्यवस्थित तरीके से फ़ाइल फ़ाइल करना है. इस तरीके की पुष्टि करने में लगने वाला समय, बाद में माइग्रेशन में निश्चित तौर पर समय बचाता है, जब आप उन ज़्यादा जटिल फ़ाइलों को हिट करते हैं.
पैटर्न को सिद्ध करें और दोहराएँ
शुक्र है कि DeviceDescriptors.js में बदलाव करने की वजह से, यह कोड बेस में शामिल हो गया. साथ ही, प्लान ने उम्मीद के मुताबिक काम किया! अब आप तैयारी करके आगे बढ़ने के लिए तैयार हैं, असल में हमने ऐसा ही किया. GitHub लेबल का इस्तेमाल करना, पुल के सभी अनुरोधों को एक साथ ग्रुप करने का एक बहुत अच्छा तरीका है. इससे हमें प्रोग्रेस को ट्रैक करने में मदद मिली.
इसे माइग्रेट करें और बाद में इसमें सुधार करें
किसी भी व्यक्तिगत JavaScript फ़ाइल के लिए हमारी प्रक्रिया इस तरह थी:
- फ़ाइल का नाम बदलकर
.jsसे.tsकरें. - टाइपस्क्रिप्ट कंपाइलर चलाएं.
- अगर कोई समस्या है, तो उसे ठीक करें.
- पुल अनुरोध बनाएं.
इन शुरुआती पुल अनुरोधों में ज़्यादातर काम मौजूदा डेटा स्ट्रक्चर के लिए टाइपस्क्रिप्ट इंटरफ़ेस को एक्सट्रैक्ट करना था. पहले पुल के अनुरोध के मामले में, जिसने 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;
इस प्रोसेस के तहत, हमने कोड बेस की हर लाइन पर काम किया और समस्याओं की जांच की. करीब कुछ साल और समय के साथ बढ़ते हुए किसी भी कोडबेस की तरह, कोड को रिफ़ैक्टर करने और स्थिति को बेहतर बनाने के कई मौके हैं. विशेष रूप से टाइपस्क्रिप्ट पर जाने के बाद, हमने ऐसे स्थान देखे जहां कोड में थोड़ा सा बदलाव करके हम कंपाइलर पर ज़्यादा भरोसा कर सकते हैं और बेहतर प्रकार की सुरक्षा पा सकते हैं.
सीधे तौर पर, ऐसे बदलाव तुरंत न करें. माइग्रेशन का लक्ष्य टाइपस्क्रिप्ट में कोडबेस को पाना है, और बड़े माइग्रेशन के दौरान हर समय आपको सॉफ़्टवेयर और अपने उपयोगकर्ताओं के लिए रुकावट पैदा करने के जोखिम के बारे में सोचना चाहिए. शुरुआत में कम से कम बदलाव करके, हमने इस जोखिम को कम रखा. फ़ाइल को मर्ज और टाइप स्क्रिप्ट पर माइग्रेट करने के बाद, हम टाइप सिस्टम से फ़ायदा पाने के लिए, कोड में सुधार करने के लिए फ़ॉलो-अप बदलाव कर सकते थे. पक्का करें कि आपने माइग्रेशन के लिए सख्त सीमाएं तय की हों और उनके अंदर रहने की कोशिश करें.
हमारे टाइप की परिभाषाओं की जांच करने के लिए टेस्ट को माइग्रेट करना
जब पूरा सोर्स कोड टाइपस्क्रिप्ट पर माइग्रेट हो जाएगा, तब हम अपने टेस्ट पर फ़ोकस कर सकते थे. हमारी जांच में कवरेज अच्छी थी, लेकिन सभी JavaScript में लिखे गए. इसका मतलब यह था कि एक चीज़ को उन्होंने टेस्ट नहीं किया और वह थी हमारी टाइप परिभाषाएं. प्रोजेक्ट के लंबे समय के लक्ष्यों में से एक (जिस पर हम अब भी काम कर रहे हैं) यह है कि हम Puppeteer की मदद से, अच्छी क्वालिटी वाली परिभाषाएं आसानी से भेज पाएं. हालांकि, हमारे कोडबेस में हमने अलग-अलग टाइप की परिभाषाओं के बारे में कोई जांच नहीं की.
हम टेस्ट को TypeScript में माइग्रेट करते हैं (एक ही प्रक्रिया का पालन करते हुए, एक-एक फ़ाइल में जाते हैं). ऐसा करने से, हमें अपने टाइपस्क्रिप्ट में कुछ समस्याओं का पता चला. ये चीज़ें, लोगों के लिए शायद हमारे लिए ढूंढने के लिए ही छोड़ दी जातीं. अब हमारे टेस्ट में न सिर्फ़ हमारे सभी फ़ंक्शन शामिल होते हैं, बल्कि यह हमारे टाइपस्क्रिप्ट की क्वालिटी की जांच भी करता है!
हमें टाइपस्क्रिप्ट से पहले ही ऐसे इंजीनियर के तौर पर काफ़ी फ़ायदा मिला है जो Puppeteer कोडबेस पर काम करते हैं. हमारे काफ़ी बेहतर सीआई परिवेश के साथ-साथ, यह Puppeteer पर काम करते समय हमें ज़्यादा काम करने में मदद करता है और TypeScript में गड़बड़ियों का पता लगाने में मदद करता है. ऐसा नहीं करने से, यह एनपीएम रिलीज़ में बदल जाता. हम अच्छी क्वालिटी की TypeScript परिभाषाएं भेजने के लिए उत्साहित हैं, ताकि Puppeteer का इस्तेमाल करने वाले सभी डेवलपर भी इस काम का फ़ायदा उठा सकें.
झलक दिखाने वाले चैनलों को डाउनलोड करना
अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर, Chrome Canary, Dev या बीटा का इस्तेमाल करें. झलक दिखाने वाले इन चैनलों की मदद से, आपको DevTools की नई सुविधाओं का ऐक्सेस मिलता है. साथ ही, सबसे नए वेब प्लैटफ़ॉर्म एपीआई को टेस्ट किया जा सकता है और उपयोगकर्ताओं के आने से पहले ही अपनी साइट पर समस्याओं का पता लगाया जा सकता है!
Chrome DevTools टीम से संपर्क करना
पोस्ट में हुई नई सुविधाओं और बदलावों या DevTools से जुड़ी किसी भी चीज़ के बारे में, नीचे दिए गए विकल्पों का इस्तेमाल करें.
- crbug.com के ज़रिए हमें कोई सुझाव या सुझाव सबमिट करें.
- DevTools में ज़्यादा विकल्प
> सहायता > DevTools से जुड़ी समस्याओं की शिकायत करें का इस्तेमाल करके, DevTools से जुड़ी समस्या की शिकायत करें. - @ChromeDevTool पर ट्वीट करें.
- हमारे DevTools YouTube वीडियो या DevTools सलाह YouTube वीडियो में नया क्या है पर टिप्पणी करें.