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

Tim van der Lippe

ध्यान दें: क्या आपको DevTools को बेहतर बनाने में मदद चाहिए? Google के उपयोगकर्ताओं पर होने वाली रिसर्च में हिस्सा लेने के लिए, यहां साइन अप करें.

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

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

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

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

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

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

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

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

हालांकि DevTools काम करता रहा, लेकिन बिना स्टैंडर्ड वाले और यूनीक मॉड्यूल सिस्टम को इस्तेमाल करने से कुछ समस्याएं आ रही थीं:

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

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

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

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

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

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

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

अगर JavaScript मॉड्यूल स्टैंडर्ड थे, तो इसका मतलब था कि VS Code जैसे IDE, Closure Compiler/TypeScript जैसे टाइप चेकर और रोलअप/मिनीफ़ायर जैसे बिल्ड टूल हमारे लिखे गए सोर्स कोड को समझ पाएंगे. इसके अलावा, जब कोई नया रखरखाव करने वाला 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 फ़ॉर्मैट की वजह से लागू की गई सीमाओं को हल करना मुश्किल था. हमने एक ऐसा समाधान बनाया जिसके साथ हम सहज महसूस करते थे. इसे बनाने से पहले हमने कई बार-बार, प्रोटोटाइप बनाने, और वास्तुकला में बदलाव करने की ज़रूरत पड़ी. हमने माइग्रेशन की रणनीति के साथ एक डिज़ाइन दस्तावेज़ तैयार किया. डिज़ाइन दस्तावेज़ में हमारा शुरुआती समय का अनुमान भी शामिल है: 2-4 हफ़्ते.

स्पॉइलर अलर्ट: माइग्रेशन के सबसे तीव्र हिस्से में 4 महीने और शुरू से अंत तक में 7 महीने लगे!

हालांकि, शुरुआती प्लान में काफ़ी समय लगा: हम DevTools रनटाइम को बताएंगे कि वह पुराने तरीके से, module.json फ़ाइल में scripts कलेक्शन में मौजूद सभी फ़ाइलों को लोड करे, जबकि modules कलेक्शन में मौजूद सभी फ़ाइलों को JavaScript मॉड्यूल के डाइनैमिक इंपोर्ट के साथ लोड करे. 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 फ़ाइल का नाम है. हमारे सोर्सट्री में, यह 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. कभी-कभी मॉड्यूलस्कोप वाले नामों के बीच टकराव होता है. सबसे मुख्य रूप से, हमने Events के कुछ खास तरह का एलान करने के पैटर्न का इस्तेमाल किया. इसमें हर सिंबल का नाम सिर्फ़ Events रखा गया था. इसका मतलब यह है कि अगर अलग-अलग फ़ाइलों में तय किए गए कई तरह के इवेंट सुने जा रहे थे, तो उन Events के import-स्टेटमेंट में नाम का टकराव होगा.
3. यह काम करने के बाद, फ़ाइलों के बीच सर्कुलर डिपेंडेंसी थी. ग्लोबल स्कोप के हिसाब से यह काम ठीक था, क्योंकि सिंबल का इस्तेमाल सभी कोड लोड होने के बाद हुआ था. हालांकि, अगर आपको import की ज़रूरत है, तो सर्कुलर डिपेंडेंसी को साफ़ तौर पर दिखाया जाएगा. यह समस्या तुरंत नहीं होती, जब तक कि आपके ग्लोबल स्कोप कोड में साइड-इफ़ेक्ट फ़ंक्शन कॉल न हों, जो DevTools में भी था. कुल मिलाकर, इस बदलाव को सुरक्षित बनाने के लिए सर्जरी और रीफ़ैक्टरिंग की ज़रूरत थी.

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

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

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

आँकड़े

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

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

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

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

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

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

झलक दिखाने वाले चैनलों को डाउनलोड करें

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

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

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

• crbug.com के ज़रिए हमें कोई सुझाव या सुझाव सबमिट करें.
• DevTools में ज़्यादा विकल्प     > सहायता > DevTools से जुड़ी समस्याओं की शिकायत करें पर जाकर, DevTools से जुड़ी समस्या की शिकायत करें.
• @ChromeDevTool पर ट्वीट करें.
• DevTools YouTube वीडियो या DevTools सलाह वाले YouTube वीडियो में नया क्या है, इस बारे में टिप्पणियां करें.