DevTools आर्किटेक्चर रीफ़्रेश: JavaScript मॉड्यूल पर माइग्रेट करना

Tim van der Lippe

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

यह पोस्ट, ब्लॉग पोस्ट की एक सीरीज़ का हिस्सा है. इसमें DevTools के आर्किटेक्चर में किए जा रहे बदलावों और इसे बनाने के तरीके के बारे में बताया गया है. हम आपको बताएंगे कि DevTools पहले कैसे काम करता था, इसके क्या फ़ायदे और सीमाएं थीं, और हमने इन सीमाओं को कम करने के लिए क्या किया है. इसलिए, आइए मॉड्यूल सिस्टम, कोड लोड करने के तरीके, और JavaScript मॉड्यूल का इस्तेमाल करने के तरीके के बारे में ज़्यादा जानें.

शुरुआत में, कुछ भी नहीं था

हालांकि, मौजूदा फ़्रंटएंड लैंडस्केप में कई तरह के मॉड्यूल सिस्टम हैं, जिनके आधार पर टूल बनाए गए हैं. साथ ही, अब स्टैंडर्ड के हिसाब से JavaScript मॉड्यूल फ़ॉर्मैट भी है, लेकिन पहली बार DevTools बनाते समय इनमें से कोई भी मौजूद नहीं था. DevTools को उस कोड के आधार पर बनाया गया है जिसे शुरुआत में 12 साल से ज़्यादा पहले WebKit में शिप किया गया था.

DevTools में मॉड्यूल सिस्टम के बारे में सबसे पहले जानकारी 2012 से आई है: सोर्स की सूची के साथ मॉड्यूल की सूची के बारे में जानकारी. यह Python इन्फ़्रास्ट्रक्चर का हिस्सा था. इसका इस्तेमाल, DevTools को कंपाइल और बिल्ड करने के लिए किया जाता था. फ़ॉलो-अप बदलाव के तहत, साल 2013 में सभी मॉड्यूल को एक अलग frontend_modules.json फ़ाइल (commit) में और फिर साल 2014 में अलग-अलग module.json फ़ाइलों (commit) में निकाला गया.

module.json फ़ाइल का उदाहरण:

{
  "dependencies": [
    "common"
  ],
  "scripts": [
    "StylePane.js",
    "ElementsPanel.js"
  ]
}

DevTools में, 2014 से module.json पैटर्न का इस्तेमाल किया जा रहा है. इससे, इसके मॉड्यूल और सोर्स फ़ाइलों की जानकारी मिलती है. इस दौरान, वेब नेटवर्क का इकोसिस्टम तेज़ी से आगे बढ़ा और कई मॉड्यूल फ़ॉर्मैट बनाए गए. इनमें UMD, CommonJS, और आखिर में स्टैंडर्ड JavaScript मॉड्यूल शामिल हैं. हालांकि, DevTools में module.json फ़ॉर्मैट ही काम कर रहा है.

DevTools लगातार काम कर रहा था, लेकिन नॉन-स्टैंडर्ड और यूनीक मॉड्यूल सिस्टम का इस्तेमाल करने में कुछ मुश्किलें आईं:

1. module.json फ़ॉर्मैट के लिए, कस्टम बिल्ड टूल की ज़रूरत होती है, जैसे कि मॉडर्न बंडलर.
2. इसमें IDE इंटिग्रेशन नहीं था. इसलिए, आधुनिक IDE के साथ काम करने वाली फ़ाइलें जनरेट करने के लिए, कस्टम टूल की ज़रूरत होती थी. जैसे, VS Code के लिए jsconfig.json फ़ाइलें जनरेट करने वाली ओरिजनल स्क्रिप्ट.
3. फ़ंक्शन, क्लास, और ऑब्जेक्ट को ग्लोबल स्कोप में रखा गया था, ताकि मॉड्यूल के बीच उन्हें शेयर किया जा सके.
4. फ़ाइलें, ऑर्डर पर निर्भर करती थीं. इसका मतलब है कि sources का क्रम अहम था. इस बात की कोई गारंटी नहीं थी कि आपके भरोसे का कोड लोड होगा. हालांकि, किसी व्यक्ति ने इसकी पुष्टि की थी.

कुल मिलाकर, DevTools में मॉड्यूल सिस्टम की मौजूदा स्थिति और अन्य (ज़्यादा इस्तेमाल किए जाने वाले) मॉड्यूल फ़ॉर्मैट का आकलन करने पर, हमें पता चला कि module.json पैटर्न से ज़्यादा समस्याएं आ रही हैं. इसलिए, यह समय आ गया है कि हम इस पैटर्न का इस्तेमाल बंद कर दें.

स्टैंडर्ड के फ़ायदे

हमने मौजूदा मॉड्यूल सिस्टम में से, JavaScript मॉड्यूल को माइग्रेट करने के लिए चुना है. उस फ़ैसले के समय, JavaScript मॉड्यूल अब भी Node.js में एक फ़्लैग के पीछे शिप हो रहे थे. साथ ही, NPM पर उपलब्ध ज़्यादातर पैकेज में ऐसा JavaScript मॉड्यूल बंडल नहीं था जिसका इस्तेमाल किया जा सके. इसके बावजूद, हमने यह फ़ैसला लिया कि JavaScript मॉड्यूल सबसे सही विकल्प हैं.

JavaScript मॉड्यूल का मुख्य फ़ायदा यह है कि यह JavaScript के लिए स्टैंडर्ड मॉड्यूल फ़ॉर्मैट है. जब हमने module.json के नुकसानों की सूची बनाई (ऊपर देखें), तो हमें पता चला कि इनमें से ज़्यादातर नुकसान, स्टैंडर्ड और यूनीक मॉड्यूल फ़ॉर्मैट का इस्तेमाल करने से जुड़े थे.

नॉन-स्टैंडर्ड मॉड्यूल फ़ॉर्मैट चुनने का मतलब है कि हमें उन बिल्ड टूल और टूल के साथ इंटिग्रेशन बनाने में समय लगाना होगा जिनका इस्तेमाल हमारे रखरखाव करने वाले करते हैं.

ये इंटिग्रेशन अक्सर नाज़ुक होते थे. साथ ही, ये सुविधाएं ठीक से काम नहीं करतीं. इन्हें इस्तेमाल करने के लिए, ज़्यादा समय की ज़रूरत पड़ती थी. कभी-कभी छोटी-मोटी गड़बड़ियां भी हो जाती थीं, जो बाद में लोगों तक पहुंच जाती थीं.

JavaScript मॉड्यूल स्टैंडर्ड थे. इसका मतलब है कि VS Code जैसे आईडीई, Closure Compiler/TypeScript जैसे टाइप चेकर, और Rollup/minifier जैसे बिल्ड टूल, हमारे लिखे गए सोर्स कोड को समझ पाएंगे. इसके अलावा, जब कोई नया मैनेजर DevTools टीम में शामिल होगा, तो उसे मालिकाना हक वाले module.json फ़ॉर्मैट को सीखने में समय नहीं बिताना पड़ेगा. हालांकि, हो सकता है कि वह पहले से ही JavaScript मॉड्यूल के बारे में जानता हो.

ज़ाहिर है, जब DevTools को पहली बार बनाया गया था, तब ऊपर बताए गए फ़ायदों में से कोई भी फ़ायदा मौजूद नहीं था. स्टैंडर्ड ग्रुप, रनटाइम लागू करने, और JavaScript मॉड्यूल का इस्तेमाल करने वाले डेवलपर को सुझाव या राय देने में सालों लग गए. हालांकि, जब JavaScript मॉड्यूल उपलब्ध हुए, तो हमारे पास यह चुनने का विकल्प था कि हम अपने फ़ॉर्मैट को बनाए रखें या नए फ़ॉर्मैट पर माइग्रेट करें.

शानदार नई सुविधाओं की कीमत

JavaScript मॉड्यूल के कई फ़ायदे हैं और हम उनका इस्तेमाल करना चाहते थे. हालांकि, हम स्टैंडर्ड module.json वर्ल्ड में ही बने रहे. JavaScript मॉड्यूल का फ़ायदा पाने के लिए, हमें तकनीकी बकाया को साफ़ करने में काफ़ी निवेश करना पड़ा. साथ ही, माइग्रेशन की ऐसी प्रोसेस को पूरा करना पड़ा जिससे सुविधाओं में रुकावट आ सकती थी और रेग्रेशन बग (ऐसी गड़बड़ी जो पहले ठीक थी, लेकिन अब ठीक नहीं है) हो सकते थे.

इस समय, हमारा सवाल "क्या हमें JavaScript मॉड्यूल का इस्तेमाल करना है?" के बजाय, एक सवाल यह था कि "JavaScript मॉड्यूल का इस्तेमाल करना कितना महंगा है?". यहां हमें यह तय करना था कि हम उपयोगकर्ताओं को किसी भी तरह की परेशानी न दें. साथ ही, इंजीनियर को माइग्रेशन में ज़्यादा समय न देना पड़े और हम कुछ समय के लिए खराब स्थिति में काम न करें.

वह आखिरी बात बहुत अहम साबित हुई. सिद्धांत रूप से, हम JavaScript मॉड्यूल का इस्तेमाल कर सकते हैं. हालांकि, माइग्रेशन के दौरान हमें ऐसा कोड मिलेगा जिसमें module.json और JavaScript मॉड्यूल, दोनों को ध्यान में रखना होगा. तकनीकी तौर पर, यह काम करना मुश्किल ही नहीं था, बल्कि इसका मतलब यह भी था कि DevTools पर काम करने वाले सभी इंजीनियरों को इस एनवायरमेंट में काम करने का तरीका पता होना चाहिए. उन्हें लगातार खुद से पूछना होगा कि "कोडबेस के इस हिस्से के लिए, क्या यह module.json या JavaScript मॉड्यूल है और मैं इसमें बदलाव कैसे करूं?".

खास जानकारी: माइग्रेशन के दौरान, हमारे साथ काम करने वाले लोगों को गाइड करने में ज़्यादा समय और मेहनत लगी.

लागत का विश्लेषण करने के बाद, हमने पाया कि JavaScript मॉड्यूल पर माइग्रेट करना अब भी फ़ायदेमंद है. इसलिए, हमारे मुख्य लक्ष्य ये थे:

1. पक्का करें कि JavaScript मॉड्यूल का इस्तेमाल करके, ज़्यादा से ज़्यादा फ़ायदे पाए जा सकें.
2. पक्का करें कि मौजूदा module.json-आधारित सिस्टम के साथ इंटिग्रेशन सुरक्षित हो और इससे उपयोगकर्ता पर बुरा असर न पड़े (रिग्रेशन बग, उपयोगकर्ता की परेशानी).
3. DevTools के सभी रखरखाव करने वालों को माइग्रेशन के दौरान गाइड करना. इसमें, गलती से होने वाली गड़बड़ियों को रोकने के लिए, पहले से मौजूद जांच और संतुलन की सुविधाएं शामिल हैं.

स्प्रेडशीट, ट्रांसफ़ॉर्मेशन, और तकनीकी बकाया

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

स्पॉइलर अलर्ट: माइग्रेशन के सबसे अहम हिस्से को पूरा करने में चार महीने लगे और शुरू से लेकर आखिर तक सात महीने लगे!

हालांकि, शुरुआती प्लान समय के साथ काम का साबित हुआ: हम DevTools रनटाइम को पुराने तरीके का इस्तेमाल करके, module.json फ़ाइल में scripts कलेक्शन में मौजूद सभी फ़ाइलों को लोड करने के लिए कहेंगे. वहीं, JavaScript मॉड्यूल के डाइनैमिक इंपोर्ट की मदद से, modules कलेक्शन में मौजूद सभी फ़ाइलों को लोड किया जाएगा. modules कलेक्शन में मौजूद किसी भी फ़ाइल के लिए, ES इंपोर्ट/एक्सपोर्ट का इस्तेमाल किया जा सकता है.

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

प्रोग्रेस शीट का स्निपेट, सार्वजनिक तौर पर यहां उपलब्ध है.

export-फ़ेज़

पहले चरण में, उन सभी सिंबल के लिए export-स्टेटमेंट जोड़ना होगा जिन्हें मॉड्यूल/फ़ाइलों के बीच शेयर किया जाना था. हर फ़ोल्डर के लिए एक स्क्रिप्ट चलाकर, डेटा अपने-आप बदल जाएगा. module.json की दुनिया में यह सिंबल मौजूद होगा:

Module.File1.exported = function() {
  console.log('exported');
  Module.File1.localFunctionInFile();
};
Module.File1.localFunctionInFile = function() {
  console.log('Local');
};

(यहां, Module मॉड्यूल का नाम है और File1 फ़ाइल का नाम है. हमारे Sourcetree में, यह front_end/module/file1.js होगा.)

इसे इस तरह बदल दिया जाएगा:

export function exported() {
  console.log('exported');
  Module.File1.localFunctionInFile();
}
export function localFunctionInFile() {
  console.log('Local');
}

/** Legacy export object */
Module.File1 = {
  exported,
  localFunctionInFile,
};

शुरुआत में, हमारा प्लान था कि इस चरण के दौरान, एक ही फ़ाइल के इंपोर्ट को फिर से लिखा जाए. उदाहरण के लिए, ऊपर दिए गए उदाहरण में हम Module.File1.localFunctionInFile को localFunctionInFile में बदल देंगे. हालांकि, हमें लगा कि अगर हम इन दोनों बदलावों को अलग करें, तो इन्हें अपने-आप लागू करना ज़्यादा आसान और सुरक्षित हो जाएगा. इसलिए, "सभी सिंबल को एक ही फ़ाइल में माइग्रेट करें", import फ़ेज़ का दूसरा सब-फ़ेज़ बन जाएगा.

किसी फ़ाइल में export कीवर्ड जोड़ने से, फ़ाइल "स्क्रिप्ट" से "मॉड्यूल" में बदल जाती है. इसलिए, DevTools के बहुत से इंफ़्रास्ट्रक्चर को इसके हिसाब से अपडेट करना पड़ा. इसमें रनटाइम (डाइनैमिक इंपोर्ट के साथ) शामिल है. हालांकि, मॉड्यूल मोड में चलाने के लिए, ESLint जैसे टूल भी शामिल हैं.

इन समस्याओं को हल करते समय, हमें पता चला कि हमारे टेस्ट "स्लोपी" मोड में चल रहे थे. JavaScript मॉड्यूल का मतलब है कि फ़ाइलें "use strict" मोड में चलती हैं. इसलिए, इसका असर हमारे टेस्ट पर भी पड़ेगा. जांच करने पर पता चला कि काफ़ी टेस्ट इस लापरवाही पर निर्भर थे. इनमें with-स्टेटमेंट का इस्तेमाल करने वाला एक टेस्ट भी शामिल था 😱.

आखिर में, export-स्टेटमेंट शामिल करने के लिए, पहले फ़ोल्डर को अपडेट करने में एक हफ़्ता लगा और रीलैंड के साथ कई कोशिशें करनी पड़ीं.

import फ़ेज़

सभी सिंबल, export-स्टेटमेंट का इस्तेमाल करके एक्सपोर्ट होने के बाद, ग्लोबल स्कोप (लेगसी) में बने रहे. इसलिए, ES इंपोर्ट का इस्तेमाल करने के लिए, हमें क्रॉस-फ़ाइल सिंबल के सभी रेफ़रंस अपडेट करने पड़े. इसका मकसद, सभी "लेगसी एक्सपोर्ट ऑब्जेक्ट" हटाना है, ताकि ग्लोबल स्कोप को साफ़ किया जा सके. हर फ़ोल्डर के लिए एक स्क्रिप्ट चलाकर, डेटा अपने-आप बदल जाएगा.

उदाहरण के लिए, module.json में मौजूद इन सिंबल के लिए:

Module.File1.exported();
AnotherModule.AnotherFile.alsoExported();
SameModule.AnotherFile.moduleScoped();

उन्हें इस तरह बदल दिया जाएगा:

import * as Module from '../module/Module.js';
import * as AnotherModule from '../another_module/AnotherModule.js';

import {moduleScoped} from './AnotherFile.js';

Module.File1.exported();
AnotherModule.AnotherFile.alsoExported();
moduleScoped();

हालांकि, इस तरीके में कुछ समस्याएं थीं:

1. हर सिंबल का नाम Module.File.symbolName नहीं था. कुछ सिंबल का नाम सिर्फ़ Module.File या Module.CompletelyDifferentName था. इस अंतर का मतलब है कि हमें पुराने ग्लोबल ऑब्जेक्ट से इंपोर्ट किए गए नए ऑब्जेक्ट के लिए, इंटरनल मैपिंग बनानी पड़ी.
2. कभी-कभी, moduleScoped नामों में अंतर होता है. खास तौर पर, हमने कुछ खास तरह के Events का एलान करने वाले पैटर्न का इस्तेमाल किया, जिसमें हर सिंबल का नाम सिर्फ़ Events था. इसका मतलब है कि अगर अलग-अलग फ़ाइलों में कई तरह के इवेंट के लिए सुनने की सुविधा चालू की गई है, तो उन Events के लिए import-स्टेटमेंट में नाम का टकराव होगा.
3. जैसा कि हमें पता चला कि अलग-अलग फ़ाइलों के बीच सर्कुलर निर्भरता अलग-अलग थी. ग्लोबल स्कोप कॉन्टेक्स्ट में यह काम सही था, क्योंकि सभी कोड लोड होने के बाद सिंबल का इस्तेमाल किया जाता था. हालांकि, अगर आपको import की ज़रूरत है, तो सर्कुलर डिपेंडेंसी को साफ़ तौर पर दिखाया जाएगा. यह समस्या तब तक नहीं होती, जब तक आपके ग्लोबल स्कोप कोड में साइड-इफ़ेक्ट फ़ंक्शन कॉल न हों. DevTools में भी साइड-इफ़ेक्ट फ़ंक्शन कॉल थे. कुल मिलाकर, बदलाव को सुरक्षित बनाने के लिए, इसमें कुछ बदलाव और फिर से फ़ॉर्मैट करने की ज़रूरत पड़ी.

JavaScript मॉड्यूल के साथ एक नई दुनिया

सितंबर 2019 में शुरू होने के छह महीने बाद, फ़रवरी 2020 में ui/ फ़ोल्डर में आखिरी बार डेटा हटाया गया. इस तारीख को, माइग्रेशन की अनौपचारिक प्रोसेस पूरी हो गई. सभी समस्याओं को हल करने के बाद, हमने माइग्रेशन की प्रोसेस को आधिकारिक तौर पर 5 मार्च, 2020 को पूरा हो गया के तौर पर मार्क कर दिया है. 🎉

अब DevTools के सभी मॉड्यूल, कोड शेयर करने के लिए JavaScript मॉड्यूल का इस्तेमाल करते हैं. हम अब भी अपने लेगसी टेस्ट के लिए या DevTools के आर्किटेक्चर के दूसरे हिस्सों के साथ इंटिग्रेट करने के लिए, ग्लोबल स्कोप (module-legacy.js फ़ाइलों में) पर कुछ सिंबल डालते हैं. इन्हें समय के साथ हटा दिया जाएगा. हालांकि, हम आने वाले समय में होने वाले डेवलपमेंट के लिए, इन समस्याओं को कोई रुकावट नहीं मानते. हमारे पास JavaScript मॉड्यूल के इस्तेमाल के लिए एक स्टाइल गाइड भी है.

आंकड़े

इस माइग्रेशन में शामिल सीएल की संख्या के लिए कंज़र्वेटिव अनुमान (बदलाव की सूची का छोटा नाम - Gerrit में इस्तेमाल किया गया शब्द, जो बदलाव को दिखाता है - GitHub पुल अनुरोध की तरह -) की संख्या करीब 250 सीएल है, जिसे ज़्यादातर 2 इंजीनियर करते हैं. हमारे पास किए गए बदलावों के साइज़ के बारे में कोई तय आंकड़े नहीं हैं, लेकिन बदली गई लाइनों का कम से कम अनुमान (हर CL के लिए इंसर्शन और मिटाए गए कुल अंतर के योग के रूप में गिना जाता है) करीब 30,000 (सभी DevTools फ़्रंटएंड कोड का ~20%) है.

export का इस्तेमाल करने वाली पहली फ़ाइल, Chrome 79 में शिप की गई थी. इसे दिसंबर 2019 में रिलीज़ किया गया था. import पर माइग्रेट करने के लिए आखिरी बदलाव, Chrome 83 में किया गया था. इसे मई 2020 में रिलीज़ किया गया था.

हमें एक ऐसी समस्या के बारे में पता है जो Chrome के स्टेबल वर्शन में भेजी गई थी. इसे इस माइग्रेशन के हिस्से के तौर पर लॉन्च किया गया था. अतिरिक्त default एक्सपोर्ट की वजह से, कमांड मेन्यू में स्निपेट अपने-आप पूरा होने की सुविधा काम नहीं कर रही. हमें कई अन्य समस्याएं भी मिली हैं. हालांकि, हमारे ऑटोमेटेड टेस्ट सुइट और Chrome Canary के उपयोगकर्ताओं ने इनकी शिकायत की. हमने इन समस्याओं को ठीक कर दिया, ताकि ये Chrome के सामान्य वर्शन के उपयोगकर्ताओं तक न पहुंच सकें.

crbug.com/1006759 पर लॉग इन करके, पूरी यात्रा देखी जा सकती है (सभी सीएल, इस गड़बड़ी से जुड़े नहीं होते. हालांकि, इनमें से ज़्यादातर सीएल, गड़बड़ी के मैसेज से जुड़े होते हैं).

हमने क्या सीखा

1. पहले लिए गए फ़ैसलों का असर आपके प्रोजेक्ट पर लंबे समय तक पड़ सकता है. JavaScript मॉड्यूल (और अन्य मॉड्यूल फ़ॉर्मैट) काफ़ी समय से उपलब्ध थे, लेकिन DevTools में माइग्रेशन की ज़रूरत नहीं थी. माइग्रेट करने का समय तय करना मुश्किल होता है. यह समय, कई बातों को ध्यान में रखकर तय किया जाता है.
2. हमारे शुरुआती अनुमान, महीनों के बजाय हफ़्तों में थे. इसकी मुख्य वजह यह है कि हमें लागत के शुरुआती विश्लेषण में उम्मीद से ज़्यादा समस्याएं मिली हैं. माइग्रेशन प्लान अच्छा था, लेकिन तकनीकी क़र्ज़ (जो हम चाहते थे उससे कहीं ज़्यादा) ब्लॉकर का था.
3. JavaScript मॉड्यूल माइग्रेशन में, तकनीकी तौर पर गड़बड़ियों को ठीक करने के लिए, बहुत सारे बदलाव किए गए. हालांकि, ये बदलाव एक-दूसरे से मेल नहीं खाते. आधुनिक स्टैंडर्ड मॉड्यूल फ़ॉर्मैट पर माइग्रेट करने से, हमने कोडिंग के सबसे सही तरीकों को आधुनिक वेब डेवलपमेंट के साथ अलाइन किया. उदाहरण के लिए, हम अपने कस्टम Python बंडलर को कम से कम रोलअप कॉन्फ़िगरेशन से बदल पाए.
4. हमारे कोडबेस पर बड़े असर (~20% कोड में बदलाव) होने के बावजूद, बहुत कम रिग्रेशन रिपोर्ट किए गए थे. शुरुआती कुछ फ़ाइलों को माइग्रेट करने में हमें कई समस्याएं आईं. हालांकि, कुछ समय बाद हमारे पास एक बेहतर और कुछ हद तक अपने-आप काम करने वाला वर्कफ़्लो बन गया. इसका मतलब यह हुआ कि इस माइग्रेशन के लिए, उपयोगकर्ताओं पर अच्छा असर नहीं पड़ा.
5. किसी खास माइग्रेशन की बारीकियों को रखरखाव करने वाले लोगों को सिखाना मुश्किल और कभी-कभी नामुमकिन होता है. इस तरह के माइग्रेशन को समझना मुश्किल होता है. साथ ही, इसके लिए डोमेन के बारे में काफ़ी जानकारी होनी चाहिए. अपने काम के लिए, उस कोड बेस में काम करने वाले दूसरे लोगों को डोमेन की जानकारी ट्रांसफ़र करना ज़रूरी नहीं है. यह जानना एक कला है कि कौनसी जानकारी शेयर की जाए और कौनसी नहीं. इसलिए, बड़े माइग्रेशन की संख्या कम करना ज़रूरी है. इसके अलावा, एक ही समय पर कई माइग्रेशन न करें.

झलक वाले चैनल डाउनलोड करना

Chrome Canary, Dev या बीटा को अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर इस्तेमाल करें. इन झलक वाले चैनलों की मदद से, आपको DevTools की नई सुविधाओं का ऐक्सेस मिलता है. साथ ही, इनसे आपको वेब प्लैटफ़ॉर्म के सबसे नए एपीआई की जांच करने में मदद मिलती है. इसके अलावा, इनकी मदद से उपयोगकर्ताओं से पहले ही अपनी साइट पर समस्याओं का पता लगाया जा सकता है!

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

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

• crbug.com पर जाकर, हमें सुझाव/राय दें या शिकायत करें. साथ ही, किसी सुविधा का अनुरोध करें.
• DevTools में more_vert ज़्यादा विकल्प > सहायता > DevTools से जुड़ी समस्या की शिकायत करें का इस्तेमाल करके, DevTools से जुड़ी समस्या की शिकायत करें.
• @ChromeDevTools पर ट्वीट करें.
• DevTools YouTube वीडियो में नया क्या है या DevTools सलाह YouTube वीडियो पर टिप्पणी की जा सकती हैं.