Puppeteer को TypeScript में माइग्रेट करना

Jack Franklin

हम DevTools टीम में TypeScript के काफ़ी फ़ैन हैं. इसलिए, DevTools में नया कोड ही लिखा जा रहा है. हम पूरे कोड बेस के एक बड़े माइग्रेशन के बीच में हैं, ताकि टाइपस्क्रिप्ट से टाइप-चेक किया जा सके. इस माइग्रेशन के बारे में ज़्यादा जानने के लिए, Chrome Dev Summit 2020 में हमारी बातचीत देखें. इसलिए, Puppeteer के कोडबेस को TypeScript में माइग्रेट करना भी सही था.

माइग्रेशन की योजना बनाना

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

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

टेस्ट किए बिना कोड में कोई बदलाव करना जोखिम भरा होता है. हालांकि, पूरी फ़ाइलों या पूरे कोडबेस में बदलाव करना, खास तौर पर जोखिम भरा होता है. मशीनरी में बदलाव करते समय, कोई चरण छूट जाना आम बात है. कई बार, टेस्ट में ऐसी समस्या का पता चला है जो लागू करने वाले और समीक्षक, दोनों को छूट गई थी.

हमने शुरुआत में कंटिन्यूअस इंटिग्रेशन (सीआई) सेटअप पर समय बिताया. हमें पता चला है कि Pull Request के लिए सीआई (कंट्रोल इंटिग्रेशन) की प्रोसेस पूरी नहीं हो पा रही थी और अक्सर काम नहीं कर रही थी. ऐसा अक्सर होता था कि हम अपने सीआई को अनदेखा कर देते थे और किसी भी तरह से, पुश अनुरोधों को मर्ज कर देते थे. ऐसा इसलिए, क्योंकि हम मानते थे कि Puppeteer में कोई समस्या नहीं है, बल्कि सीआई में एक बार की गई गड़बड़ी है.

कुछ सामान्य रखरखाव और नियमित टेस्ट फ़्लेक को ठीक करने के लिए खास समय देने के बाद, हम इसे लगातार पास होने की स्थिति में ले आए. इससे हमें सीआई को सुनने और यह जानने में मदद मिली कि कोई गड़बड़ी होने पर, असल समस्या का पता चलता है. यह काम आकर्षक नहीं है, और कभी न खत्म होने वाले सीआई को देखकर परेशानी होती है. हालांकि, हमारे टेस्ट सुइट का भरोसेमंद तरीके से काम करना अहम था, क्योंकि हमें पुल के अनुरोधों की संख्या में बढ़ोतरी दिख रही थी.

एक फ़ाइल चुनना और उसे लैंड करना

इस समय, हमारा माइग्रेशन पूरा हो चुका था. साथ ही, हमारे पास एक बेहतरीन सीआई सर्वर था, जिसमें कई टेस्ट मौजूद थे. हमने किसी भी फ़ाइल को चुनने के बजाय, माइग्रेट करने के लिए जान-बूझकर एक छोटी फ़ाइल चुनी. यह एक काम का तरीका है, क्योंकि इससे आपको अपनी प्लान की गई प्रोसेस की पुष्टि करने में मदद मिलती है. अगर यह इस फ़ाइल पर काम करता है, तो इसका मतलब है कि आपका तरीका सही है. अगर नहीं, तो आपको फिर से शुरुआत करनी होगी.

इसके अलावा, फ़ाइल के हिसाब से बदलाव करने से (और Puppeteer के नियमित रिलीज़ के साथ, ताकि सभी बदलाव एक ही npm वर्शन में न भेजे जाएं) जोखिम कम हो गया. हमने पहली फ़ाइल के तौर पर DeviceDescriptors.js को चुना, क्योंकि यह कोडबेस में सबसे आसान फ़ाइलों में से एक थी. यह काम आसानी से करना थोड़ा बोझिल हो सकता है और इतना छोटा बदलाव भी करना मुश्किल लगता है, लेकिन इसका लक्ष्य 'तुरंत बड़े बदलाव' करना नहीं, बल्कि सावधानी से आगे बढ़ना है और हर एक फ़ाइल को सिलसिलेवार तरीके से फ़ाइल के तौर पर दर्ज करना है. इस तरीके की पुष्टि करने में लगने वाला समय, माइग्रेशन के दौरान ज़्यादा मुश्किल फ़ाइलों को माइग्रेट करने में ज़रूर बचता है.

पैटर्न की पुष्टि करना और उसे दोहराना

शुक्र है कि DeviceDescriptors.js में बदलाव करके, उसे कोडबेस में शामिल कर लिया गया. साथ ही, प्लान हमारी उम्मीद के मुताबिक काम कर रहा है! अब आप आगे बढ़ने के लिए तैयार हैं. ठीक वैसा ही हमने किया. GitHub लेबल का इस्तेमाल करके, सभी पुल रिक्वेस्ट को एक साथ ग्रुप किया जा सकता है. हमें यह तरीका, प्रोग्रेस को ट्रैक करने के लिए काफ़ी मददगार लगा.

इसे माइग्रेट करें और बाद में बेहतर बनाएं

किसी भी व्यक्तिगत JavaScript फ़ाइल के लिए हमारी प्रक्रिया यह थी:

  1. फ़ाइल का नाम .js से बदलकर .ts करें.
  2. TypeScript कंपाइलर को चालू करें.
  3. किसी भी समस्या को ठीक करें.
  4. पुल का अनुरोध बनाएं.

शुरुआती पुल रिक्वेस्ट में ज़्यादातर काम, मौजूदा डेटा स्ट्रक्चर के लिए 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 से जुड़ी किसी भी अन्य चीज़ के बारे में चर्चा करने के लिए, इन विकल्पों का इस्तेमाल करें.