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

Jack Franklin

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

माइग्रेशन की प्लानिंग करना

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

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

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

हमने सबसे पहले लगातार इंटिग्रेशन (सीआई) सेटअप करने में समय लगाया. हमें पता चला है कि पुल का अनुरोधों के ख़िलाफ़ सीआई (CI) रन में गड़बड़ियां हो रही हैं और वे अक्सर फ़ेल हो रहे हैं. ऐसा अक्सर होता था. इसलिए, हमें सीआई को अनदेखा करने और पुल अनुरोधों को मर्ज करने की आदत पड़ गई थी. हम यह मान लेते थे कि सीआई में गड़बड़ी, 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 Canary, Dev या Beta को अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर इस्तेमाल करें. इन प्रीव्यू चैनलों से, आपको DevTools की नई सुविधाओं का ऐक्सेस मिलता है. साथ ही, आपको वेब प्लैटफ़ॉर्म के नए एपीआई को टेस्ट करने का मौका मिलता है. इसके अलावा, आपको अपनी साइट पर मौजूद समस्याओं का पता लगाने में मदद मिलती है. इससे पहले कि आपके उपयोगकर्ता इन समस्याओं का पता लगाएं!

Chrome DevTools टीम से संपर्क करना

नई सुविधाओं, अपडेट या DevTools से जुड़ी किसी अन्य चीज़ के बारे में चर्चा करने के लिए, इन विकल्पों का इस्तेमाल करें.