जैसा कि आपको पता होगा, 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 काम करता रहा, लेकिन स्टैंडर्ड और यूनीक मॉड्यूल सिस्टम का इस्तेमाल करने से कुछ समस्याएं आती थीं:
module.json
फ़ॉर्मैट के लिए, कस्टम बिल्ड टूल की ज़रूरत होती है, जैसे कि मॉडर्न बंडलर.- इसमें IDE इंटिग्रेशन नहीं था. इसलिए, आधुनिक IDE के साथ काम करने वाली फ़ाइलें जनरेट करने के लिए, कस्टम टूल की ज़रूरत होती थी. जैसे, VS Code के लिए jsconfig.json फ़ाइलें जनरेट करने वाली ओरिजनल स्क्रिप्ट.
- फ़ंक्शन, क्लास, और ऑब्जेक्ट को ग्लोबल स्कोप में रखा गया था, ताकि मॉड्यूल के बीच उन्हें शेयर किया जा सके.
- फ़ाइलों का क्रम अहम था. इसका मतलब है कि
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 मॉड्यूल पर माइग्रेट करना अब भी फ़ायदेमंद है. इसलिए, हमारे मुख्य लक्ष्य ये थे:
- पक्का करें कि JavaScript मॉड्यूल का इस्तेमाल करके, ज़्यादा से ज़्यादा फ़ायदे पाए जा सकें.
- पक्का करें कि मौजूदा
module.json
-आधारित सिस्टम के साथ इंटिग्रेशन सुरक्षित हो और इससे उपयोगकर्ता पर कोई बुरा असर न पड़े (रिग्रेशन बग, उपयोगकर्ता की परेशानी). - 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();
हालांकि, इस तरीके में कुछ समस्याएं थीं:
- हर सिंबल का नाम
Module.File.symbolName
नहीं था. कुछ सिंबल का नाम सिर्फ़Module.File
याModule.CompletelyDifferentName
था. इस अंतर का मतलब है कि हमें पुराने ग्लोबल ऑब्जेक्ट से इंपोर्ट किए गए नए ऑब्जेक्ट के लिए, इंटरनल मैपिंग बनानी पड़ी. - कभी-कभी, moduleScoped नामों में अंतर होता है.
खास तौर पर, हमने कुछ खास तरह के
Events
को एलान करने के लिए पैटर्न का इस्तेमाल किया, जहां हर सिंबल का नाम सिर्फ़Events
था. इसका मतलब है कि अगर अलग-अलग फ़ाइलों में कई तरह के इवेंट के लिए सुनने की सुविधा चालू की गई है, तो उनEvents
के लिएimport
-स्टेटमेंट में नाम का टकराव होगा. - जांच करने पर पता चला कि फ़ाइलों के बीच सर्कुलर डिपेंडेंसी थी.
ग्लोबल स्कोप के संदर्भ में, यह ठीक था, क्योंकि सिंबल का इस्तेमाल, पूरा कोड लोड होने के बाद किया गया था.
हालांकि, अगर आपको
import
की ज़रूरत है, तो सर्कुलर डिपेंडेंसी को साफ़ तौर पर दिखाया जाएगा. यह समस्या तब तक नहीं होती, जब तक आपके ग्लोबल स्कोप कोड में साइड-इफ़ेक्ट फ़ंक्शन कॉल न हों. DevTools में भी साइड-इफ़ेक्ट फ़ंक्शन कॉल थे. कुल मिलाकर, बदलाव को सुरक्षित बनाने के लिए, इसमें कुछ बदलाव और रीफ़ैक्टरिंग की ज़रूरत पड़ी.
JavaScript मॉड्यूल की मदद से नई दुनिया
सितंबर 2019 में शुरू होने के छह महीने बाद, फ़रवरी 2020 में ui/
फ़ोल्डर में आखिरी बार डेटा हटाया गया.
इस तारीख को, माइग्रेशन की अनौपचारिक प्रोसेस पूरी हो गई.
हमने माइग्रेशन की प्रोसेस को आधिकारिक तौर पर 5 मार्च, 2020 को पूरा हो गया के तौर पर मार्क कर दिया है. 🎉
अब DevTools के सभी मॉड्यूल, कोड शेयर करने के लिए JavaScript मॉड्यूल का इस्तेमाल करते हैं.
हम अब भी अपने लेगसी टेस्ट के लिए या DevTools के आर्किटेक्चर के दूसरे हिस्सों के साथ इंटिग्रेट करने के लिए, ग्लोबल स्कोप (module-legacy.js
फ़ाइलों में) पर कुछ सिंबल डालते हैं.
इन्हें समय के साथ हटा दिया जाएगा. हालांकि, हम आने वाले समय में होने वाले डेवलपमेंट के लिए, इन समस्याओं को कोई रुकावट नहीं मानते.
हमारे पास JavaScript मॉड्यूल के इस्तेमाल के लिए स्टाइल गाइड भी है.
आंकड़े
इस माइग्रेशन में शामिल सीएल (बदलाव सूची के लिए छोटा नाम - Gerrit में इस्तेमाल किया जाने वाला शब्द, जो बदलाव को दिखाता है - GitHub के पुल अनुरोध जैसा) की संख्या का अनुमानित अनुमान 250 सीएल है, जिसे मुख्य रूप से दो इंजीनियर ने किया है. हमारे पास किए गए बदलावों के बारे में सटीक आंकड़े नहीं हैं. हालांकि, बदली गई लाइनों का अनुमानित हिसाब लगाने पर, यह पता चलता है कि 30,000 लाइनों में बदलाव किया गया है. यह DevTools के सभी फ़्रंटएंड कोड का करीब 20% है. यह हिसाब, हर सीएल के लिए जोड़ी गई और हटाई गई लाइनों के बीच के अंतर के आधार पर लगाया गया है.
export
का इस्तेमाल करने वाली पहली फ़ाइल, Chrome 79 में शिप की गई थी. इसे दिसंबर 2019 में रिलीज़ किया गया था.
import
पर माइग्रेट करने के लिए आखिरी बदलाव, Chrome 83 में किया गया था. इसे मई 2020 में रिलीज़ किया गया था.
हमें एक ऐसी समस्या के बारे में पता है जो Chrome के स्टेबल वर्शन में भेजी गई थी. इसे इस माइग्रेशन के हिस्से के तौर पर लॉन्च किया गया था.
अतिरिक्त default
एक्सपोर्ट की वजह से, कमांड मेन्यू में स्निपेट अपने-आप पूरा होने की सुविधा काम नहीं कर रही.
हमें कई अन्य समस्याएं भी मिली हैं. हालांकि, हमारे ऑटोमेटेड टेस्ट सुइट और Chrome Canary के उपयोगकर्ताओं ने इनकी शिकायत की. हमने इन समस्याओं को ठीक कर दिया, ताकि ये Chrome के सामान्य वर्शन के उपयोगकर्ताओं तक न पहुंच सकें.
crbug.com/1006759 पर लॉग की गई पूरी प्रोसेस देखी जा सकती है. हालांकि, इस गड़बड़ी से जुड़े सभी सीएल नहीं, बल्कि ज़्यादातर सीएल लॉग किए गए हैं.
हमने क्या सीखा
- पहले लिए गए फ़ैसलों का असर आपके प्रोजेक्ट पर लंबे समय तक पड़ सकता है. JavaScript मॉड्यूल (और अन्य मॉड्यूल फ़ॉर्मैट) काफ़ी समय से उपलब्ध थे, लेकिन DevTools में माइग्रेशन की ज़रूरत नहीं थी. माइग्रेट करने का समय तय करना मुश्किल होता है. यह समय, कई बातों को ध्यान में रखकर तय किया जाता है.
- हमारे शुरुआती अनुमान, महीनों के बजाय हफ़्तों में थे. इसकी वजह यह है कि हमें लागत के शुरुआती विश्लेषण में, जितनी समस्याओं का अनुमान था उससे ज़्यादा समस्याएं मिली हैं. माइग्रेशन का प्लान अच्छा था, लेकिन तकनीकी बकाया (हम चाहेंगे कि यह ज़्यादा न हो) अक्सर रुकावट बनता था.
- JavaScript मॉड्यूल माइग्रेशन में, तकनीकी तौर पर गड़बड़ियों को ठीक करने के लिए, बहुत सारे बदलाव किए गए. हालांकि, ये बदलाव एक-दूसरे से मेल नहीं खाते. आधुनिक स्टैंडर्ड मॉड्यूल फ़ॉर्मैट पर माइग्रेट करने से, हमने कोडिंग के सबसे सही तरीकों को आधुनिक वेब डेवलपमेंट के साथ अलाइन किया. उदाहरण के लिए, हम अपने कस्टम Python बंडलर को कम से कम रोलअप कॉन्फ़िगरेशन से बदल पाए.
- हमारे कोडबेस पर काफ़ी असर पड़ने के बावजूद (~20% कोड बदला गया), बहुत कम रेग्रेशन की शिकायत मिली. शुरुआती कुछ फ़ाइलों को माइग्रेट करने में हमें कई समस्याएं आईं. हालांकि, कुछ समय बाद हमारे पास एक बेहतर और कुछ हद तक अपने-आप काम करने वाला वर्कफ़्लो बन गया. इसका मतलब है कि इस माइग्रेशन से, हमारे उन उपयोगकर्ताओं पर कम से कम असर पड़ा जो पहले से ही हमारे प्लैटफ़ॉर्म का इस्तेमाल कर रहे थे.
- किसी माइग्रेशन की बारीकियों को, साथ मिलकर प्रोजेक्ट मैनेज करने वाले लोगों को सिखाना मुश्किल होता है. कभी-कभी तो यह मुमकिन भी नहीं होता. इस तरह के माइग्रेशन को समझना मुश्किल होता है. साथ ही, इसके लिए डोमेन के बारे में काफ़ी जानकारी होनी चाहिए. उस डोमेन के बारे में जानकारी, उसी कोडबेस पर काम करने वाले दूसरे लोगों को ट्रांसफ़र करना, उनके काम के हिसाब से ज़रूरी नहीं है. यह जानना एक कला है कि कौनसी जानकारी शेयर की जाए और कौनसी नहीं. इसलिए, बड़े माइग्रेशन की संख्या कम करना ज़रूरी है. इसके अलावा, एक ही समय पर कई माइग्रेशन न करें.
झलक वाले चैनल डाउनलोड करना
Chrome कैनरी, डेवलपर या बीटा को अपने डिफ़ॉल्ट डेवलपमेंट ब्राउज़र के तौर पर इस्तेमाल करें. इन झलक वाले चैनलों की मदद से, आपको DevTools की नई सुविधाओं का ऐक्सेस मिलता है. साथ ही, इनसे आपको वेब प्लैटफ़ॉर्म के सबसे नए एपीआई की जांच करने में मदद मिलती है. इसके अलावा, इनकी मदद से उपयोगकर्ताओं से पहले ही अपनी साइट पर समस्याओं का पता लगाया जा सकता है!
Chrome DevTools की टीम से संपर्क करना
DevTools से जुड़ी नई सुविधाओं, अपडेट या किसी भी अन्य चीज़ के बारे में चर्चा करने के लिए, यहां दिए गए विकल्पों का इस्तेमाल करें.
- crbug.com पर जाकर, हमें सुझाव/राय दें या शिकायत करें. साथ ही, किसी सुविधा का अनुरोध करें.
- DevTools में ज़्यादा विकल्प > सहायता > DevTools से जुड़ी समस्या की शिकायत करें का इस्तेमाल करके, DevTools से जुड़ी समस्या की शिकायत करें.
- @ChromeDevTools पर ट्वीट करें.
- DevTools के YouTube वीडियो में नया क्या है या DevTools के बारे में सलाह देने वाले YouTube वीडियो पर टिप्पणियां करें.