उत्पादन में जावास्क्रिप्ट मॉड्यूल का उपयोग करना: मामलों की वर्तमान स्थिति। भाग 1

दो साल पहले, मैंने एक ऐसी तकनीक के बारे में लिखा था जिसे अब आमतौर पर मॉड्यूल / नामांकित पैटर्न कहा जाता है। इसका एप्लिकेशन आपको ES2015 + की क्षमताओं का उपयोग करके जावास्क्रिप्ट कोड लिखने की अनुमति देता है, और फिर कोड बेस के दो संस्करण बनाने के लिए बंडल और ट्रांसप्लर्स का उपयोग करता है। उनमें से एक में आधुनिक वाक्यविन्यास होता है (इसे <script type="module"> जैसी संरचना का उपयोग करके लोड किया जाता है, और दूसरा ES5 सिंटैक्स है (इसे <script nomodule> का उपयोग करके लोड किया गया है)। मॉड्यूल / नामांकित पैटर्न ब्राउज़रों को समर्थन मॉड्यूल भेजने की अनुमति देता है। ब्राउज़र की तुलना में बहुत कम कोड जो इस सुविधा का समर्थन नहीं करते हैं, अब यह पैटर्न अधिकांश वेब फ्रेमवर्क और कमांड लाइन टूल द्वारा समर्थित है।



पहले, यहां तक ​​कि आधुनिक जावास्क्रिप्ट कोड को उत्पादन में भेजने की क्षमता पर विचार करते हुए, और यद्यपि अधिकांश ब्राउज़र ने मॉड्यूल का समर्थन किया, मैंने बंडल में कोड इकट्ठा करने की सिफारिश की।

क्यों? ज्यादातर क्योंकि मुझे लग रहा था कि ब्राउज़र में लोडिंग मॉड्यूल धीमा था। भले ही हाल के प्रोटोकॉल, जैसे कि HTTP / 2, सैद्धांतिक रूप से कई फ़ाइलों के कुशल लोडिंग का समर्थन करते थे, उस समय सभी प्रदर्शन अध्ययनों ने निष्कर्ष निकाला कि बंडल का उपयोग करना अभी भी मॉड्यूल का उपयोग करने से अधिक कुशल है।

लेकिन यह स्वीकार किया जाना चाहिए कि वे अध्ययन अधूरे थे। उन मॉड्यूल का उपयोग करने वाले परीक्षण मामलों का अध्ययन किया गया, जिनमें गैर-अनुकूलित और गैर-न्यूनतम स्रोत कोड फाइलें शामिल थीं, जिन्हें उत्पादन में तैनात किया गया था। अनुकूलित क्लासिक स्क्रिप्ट के साथ मॉड्यूल के साथ अनुकूलित बंडल की कोई तुलना नहीं थी।

हालांकि, ईमानदार होने के लिए, उस समय मॉड्यूल को तैनात करने का कोई इष्टतम तरीका नहीं था। लेकिन अब, बंडलर प्रौद्योगिकियों में कुछ आधुनिक सुधारों के लिए धन्यवाद, स्थिर और गतिशील दोनों आयात आदेशों का उपयोग करके ES2015 मॉड्यूल के रूप में उत्पादन कोड को तैनात करना संभव है, और एक ही समय में उच्च प्रदर्शन प्राप्त करने की तुलना में उपलब्ध विकल्पों का उपयोग करके प्राप्त किया जा सकता है, जिसमें मॉड्यूल का उपयोग नहीं किया जाता है।

यह ध्यान दिया जाना चाहिए कि जिस साइट पर मूल सामग्री प्रकाशित की गई है, उस अनुवाद का पहला भाग जिसे हम आज प्रकाशित करते हैं, मॉड्यूल कई महीनों के लिए उत्पादन में उपयोग किया गया है।

मॉड्यूल के बारे में गलत धारणाएं

कई लोग जिनके साथ मैंने बात की, वे पूरी तरह से मॉड्यूल को अस्वीकार करते हैं, यहां तक ​​कि उन्हें बड़े पैमाने पर उत्पादन अनुप्रयोगों के विकल्पों में से एक के रूप में भी नहीं मानते हैं। उनमें से कई बहुत अध्ययन का हवाला देते हैं जो मैंने पहले ही उल्लेख किया है। अर्थात्, इसका वह हिस्सा, जो बताता है कि उत्पादन में मॉड्यूल का उपयोग नहीं किया जाना चाहिए, जब तक कि यह "छोटे वेब अनुप्रयोगों का सवाल न हो, जिसमें 100 से कम मॉड्यूल शामिल हों जो अपेक्षाकृत" छोटे "निर्भरता वाले पेड़ (जो कि) में भिन्न हों - जिसकी गहराई 5 स्तरों से अधिक नहीं है)

यदि आपने कभी भी अपने किसी भी प्रोजेक्ट के node_modules निर्देशिका पर ध्यान दिया है, तो आप शायद जानते हैं कि एक छोटे से आवेदन में भी आसानी से 100 से अधिक निर्भरता मॉड्यूल हो सकते हैं। मैं आपको सबसे लोकप्रिय npm पैकेजों में से कितने मॉड्यूल उपलब्ध हैं, इस पर एक नज़र डालना चाहता हूं।

यह वह जगह है जहां मॉड्यूल के बारे में मुख्य गलत धारणा निहित है। प्रोग्रामर मानते हैं कि जब उत्पादन में मॉड्यूल का उपयोग करने की बात आती है, तो उनके पास केवल दो विकल्प होते हैं। पहला अपने मौजूदा रूप में सभी स्रोत कोड को तैनात करना है ( node_modules निर्देशिका सहित)। दूसरा बिल्कुल भी मॉड्यूल का उपयोग नहीं करना है।

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

लेकिन आप जानते हैं क्या? तथ्य यह है कि आप यह सब उपयोग कर सकते हैं और उत्पादन में मॉड्यूल का उपयोग कर सकते हैं।

वास्तव में, मॉड्यूल एक ऐसा प्रारूप है जिसे हमें बदलने की कोशिश करनी चाहिए, क्योंकि ब्राउज़र पहले से ही जानते हैं कि मॉड्यूल को कैसे लोड किया जाए (और जो ब्राउज़र ऐसा नहीं कर सकते हैं वह कोड के अतिरिक्त संस्करण को लोड कर सकता है)। यदि आप उस कोड को देखते हैं जो सबसे लोकप्रिय बंडल उत्पन्न करता है, तो आपको कई टेम्पलेट टुकड़े मिलेंगे, जिनका उद्देश्य केवल अन्य कोड को गतिशील रूप से लोड करना और निर्भरता का प्रबंधन करना है। लेकिन यह सब आवश्यक नहीं होगा यदि हम सिर्फ मॉड्यूल और भाव import और export उपयोग करते हैं।

सौभाग्य से, कम से कम एक लोकप्रिय आधुनिक बंडलर्स ( रोलअप ) आउटपुट डेटा के रूप में मॉड्यूल का समर्थन करता है। इसका मतलब है कि आप कोड को एक बंडलर के साथ संसाधित कर सकते हैं और उत्पादन में मॉड्यूल को तैनात कर सकते हैं (कोड को लोड करने के लिए टेम्पलेट टुकड़े का उपयोग किए बिना)। और, चूंकि रोलअप में ट्री-शेकिंग एल्गोरिदम (मैंने बंडलों में सबसे अच्छा देखा है) का एक उत्कृष्ट कार्यान्वयन है, रोलअप का उपयोग करके मॉड्यूल के रूप में प्रोग्राम बनाना आपको कोड प्राप्त करने की अनुमति देता है जो आवेदन करते समय प्राप्त समान कोड के आकार से छोटा होता है अन्य तंत्र आज उपलब्ध हैं।

यह ध्यान दिया जाना चाहिए कि वे पार्सल के अगले संस्करण में मॉड्यूल के लिए समर्थन जोड़ने की योजना बनाते हैं। वेबपैक अभी तक आउटपुट प्रारूप के रूप में मॉड्यूल का समर्थन नहीं करता है, लेकिन यहां यह है - चर्चा जो इस मुद्दे पर ध्यान केंद्रित करती है।

मॉड्यूल के बारे में एक और गलत धारणा यह है कि कुछ लोगों का मानना ​​है कि मॉड्यूल का उपयोग केवल तभी किया जा सकता है जब परियोजना निर्भरता के 100% मॉड्यूल का उपयोग करें। दुर्भाग्य से (मैं इसे बहुत खेदजनक मानता हूं), अभी भी अधिकांश एनपीएम पैकेज कॉमनजेएस प्रारूप (कुछ मॉड्यूल, यहां तक ​​कि जो ईएस2015 सुविधाओं का उपयोग करते हुए लिखे गए हैं, वे एनपीएम पर प्रकाशित होने से पहले कॉमनजस प्रारूप में अनुवादित किए जाते हैं) का उपयोग करने के लिए तैयार किए जा रहे हैं!

यहां, फिर से, मैं यह नोट करना चाहता हूं कि रोलअप में एक प्लगइन ( रोलअप-प्लगइन-कॉमनज ) है जो कॉमनजस का उपयोग करके लिखा गया इनपुट स्रोत कोड लेता है और इसे ईएस2015 कोड में कनवर्ट करता है। निश्चित रूप से, यह बेहतर होगा कि बहुत शुरुआत से उपयोग की गई निर्भरता प्रारूप ES2015 मॉड्यूल प्रारूप का उपयोग करता है। लेकिन अगर कुछ निर्भरताएं ऐसी नहीं हैं, तो यह आपको उत्पादन में मॉड्यूल का उपयोग करने वाली परियोजनाओं को तैनात करने से नहीं रोकता है।

इस लेख के निम्नलिखित भागों में, मैं आपको प्रदर्शित करने जा रहा हूं कि कैसे मैं उन बंडलों में परियोजनाएं एकत्र करता हूं जो मॉड्यूल का उपयोग करते हैं (गतिशील आयात और कोड पृथक्करण सहित), मैं इस बारे में बात करने जा रहा हूं कि ऐसे समाधान आमतौर पर शास्त्रीय लिपियों की तुलना में अधिक उत्पादक क्यों होते हैं, और दिखाते हैं कि वे कैसे काम करते हैं ऐसे ब्राउज़रों के साथ जो मॉड्यूल का समर्थन नहीं करते हैं।

इष्टतम कोड बिल्ड रणनीति

उत्पादन के लिए बिल्डिंग कोड हमेशा विभिन्न समाधानों के पेशेवरों और विपक्षों को संतुलित करने का एक प्रयास है। एक तरफ, डेवलपर चाहता है कि उसका कोड जल्दी से जल्दी लोड और निष्पादित हो। दूसरी ओर, वह कोड डाउनलोड नहीं करना चाहता है जो परियोजना के उपयोगकर्ताओं द्वारा उपयोग नहीं किया जाएगा।

इसके अलावा, डेवलपर्स को विश्वास की आवश्यकता है कि उनका कोड कैशिंग के लिए सबसे उपयुक्त है। कोड बंडलिंग की बड़ी समस्या यह है कि कोड में कोई भी बदलाव, यहां तक ​​कि एक परिवर्तित लाइन, पूरे बंडल के कैश को अमान्य कर देती है। यदि आप हजारों छोटे मॉड्यूलों से युक्त एक एप्लिकेशन को तैनात करते हैं (ठीक उसी रूप में प्रस्तुत किया जाता है जिसमें वे स्रोत कोड में मौजूद हैं), तो आप सुरक्षित रूप से कोड में मामूली बदलाव कर सकते हैं और एक ही समय में जान सकते हैं कि अधिकांश एप्लिकेशन कोड कैश हो जाएगा । लेकिन, जैसा कि मैंने पहले ही कहा है, विकास के लिए इस तरह के दृष्टिकोण का मतलब शायद यह हो सकता है कि जब आप किसी संसाधन पर पहली बार कोड लोड कर रहे हैं तो अधिक पारंपरिक दृष्टिकोणों का उपयोग करने में अधिक समय लग सकता है।

नतीजतन, हम एक मुश्किल काम का सामना करते हैं, जो कि बंडलों को भागों में तोड़ने का सही तरीका खोजना है। हमें लोडिंग सामग्री की गति और उनके दीर्घकालिक कैशिंग के बीच सही संतुलन बनाना होगा।

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

मेरा मानना ​​है कि कोड को यथासंभव छोटे टुकड़ों में तोड़ दिया जाना चाहिए। यह टुकड़ों के आकार को कम करने के लायक है जब तक कि उनकी संख्या इतनी बढ़ जाती है कि यह परियोजना लोडिंग गति को प्रभावित करेगा। और यद्यपि मैं निश्चित रूप से सलाह देता हूं कि हर कोई स्थिति के अपने विश्लेषण को अंजाम दे, यदि आप मेरे द्वारा उल्लिखित अध्ययन में की गई अनुमानित गणनाओं पर विश्वास करते हैं, जब 100 मॉड्यूल से कम लोड हो रहा है, तो लोडिंग में कोई ध्यान देने योग्य मंदी नहीं है। 50 से कम फ़ाइलों को डाउनलोड करने पर HTTP / 2 प्रदर्शन पर एक अलग अध्ययन ने ध्यान देने योग्य परियोजना मंदी का खुलासा नहीं किया। हालांकि, हमने केवल उन विकल्पों का परीक्षण किया, जिनमें फ़ाइलों की संख्या 1, 6, 50 और 1000 थी। नतीजतन, शायद 100 फाइलें ऐसा मूल्य है जिसे आप डाउनलोड स्पीड में खोने के डर के बिना आसानी से नेविगेट कर सकते हैं।

तो, आक्रामक तरीके से सबसे अच्छा तरीका क्या है, लेकिन बहुत आक्रामक तरीके से कोड को भागों में विभाजित नहीं करना है? डायनामिक इम्पोर्ट कमांड के आधार पर कोड को विभाजित करने के अलावा, मैं आपको सलाह दूंगा कि कोड को एनपीएम पैकेज में विभाजित करने पर बारीकी से ध्यान दें। इस दृष्टिकोण के साथ, node_modules फ़ोल्डर से प्रोजेक्ट में जो आयात किया जाता है वह पैकेज नाम के आधार पर समाप्त कोड के एक अलग टुकड़े में आता है।

पैकेज पृथक्करण

मैंने ऊपर कहा कि कुछ बंडलों की आधुनिक क्षमता मॉड्यूल आधारित परियोजनाओं को तैनात करने के लिए एक उच्च प्रदर्शन योजना को व्यवस्थित करना संभव बनाती है। मैं जिस बारे में बात कर रहा था वह दो नई रोलअप विशेषताओं द्वारा दर्शाया गया है। डायनामिक import() कमांड्स ( v1.0.0 में जोड़ा गया import() माध्यम से पहला स्वचालित कोड पृथक्करण है । दूसरा विकल्प मैनुअल कोड पृथक्करण है जो प्रोग्राम के आधार पर manualChunks विकल्प ( v1.11.0 में जोड़ा गया) पर आधारित है।

इन दो विशेषताओं के लिए धन्यवाद, अब बिल्ड प्रक्रिया को कॉन्फ़िगर करना बहुत आसान है, जिसमें कोड पैकेज स्तर पर विभाजित है।

यहां एक उदाहरण कॉन्फ़िगरेशन है जो manualChunks विकल्प का उपयोग करता है, manualChunks लिए manualChunks से आयातित प्रत्येक मॉड्यूल कोड के एक अलग टुकड़े में आता है, जिसका नाम पैकेज नाम (तकनीकी रूप से, node_modules निर्देशिका में पैकेज निर्देशिका का नाम) से node_modules :

 export default {  input: {    main: 'src/main.mjs',  },  output: {    dir: 'build',    format: 'esm',    entryFileNames: '[name].[hash].mjs',  },  manualChunks(id) {    if (id.includes('node_modules')) {      //   ,    `node_modules`.      //   - ,       .      const dirs = id.split(path.sep);      return dirs[dirs.lastIndexOf('node_modules') + 1];    }  }, } 

manualChunk विकल्प एक फ़ंक्शन को स्वीकार करता है जो एकल तर्क के रूप में, मॉड्यूल फ़ाइल का पथ स्वीकार करता है। यह फ़ंक्शन एक स्ट्रिंग नाम वापस कर सकता है। यह जो रिटर्न देता है वह विधानसभा के एक टुकड़े को इंगित करेगा जिसमें वर्तमान मॉड्यूल को जोड़ा जाना चाहिए। यदि फ़ंक्शन कुछ भी वापस नहीं करता है, तो मॉड्यूल को डिफ़ॉल्ट टुकड़ा में जोड़ा जाएगा।

एक एप्लिकेशन पर विचार करें जो cloneDeep() , cloneDeep() debounce() और lodash-es find() lodash-es को lodash-es पैकेज से lodash-es । यदि आप इस एप्लिकेशन को बनाते समय उपरोक्त कॉन्फ़िगरेशन को लागू करते हैं, तो इनमें से प्रत्येक मॉड्यूल (साथ ही इन मॉड्यूल द्वारा आयातित प्रत्येक lodash मॉड्यूल) को एक आउटपुट आउटपुट फ़ाइल में रखा जाएगा, जैसे npm.lodash-es.XXXX.mjs (यहां XXXX अद्वितीय है) मॉड्यूल फ़ाइल हैश lodash-es टुकड़ा में हैश)।

फ़ाइल के अंत में, आपको निम्न की तरह एक निर्यात अभिव्यक्ति दिखाई देगी। कृपया ध्यान दें कि इस अभिव्यक्ति में खंड में जोड़े गए मॉड्यूल के लिए केवल निर्यात आदेश हैं, और सभी lodash मॉड्यूल नहीं हैं।

 export {cloneDeep, debounce, find}; 

फिर, यदि किसी अन्य खंड में कोड इन lodash मॉड्यूल (शायद केवल lodash debounce() विधि) का उपयोग करता है, तो इन टुकड़ों में, उनके ऊपरी हिस्से में, एक आयात अभिव्यक्ति होगी जो इस तरह दिखता है:

 import {debounce} from './npm.lodash.XXXX.mjs'; 

उम्मीद है कि इस उदाहरण ने इस सवाल को स्पष्ट किया कि रोलअप में मैनुअल कोड पृथक्करण कैसे काम करता है। इसके अलावा, मुझे लगता है कि import और export अभिव्यक्तियों का उपयोग करके कोड पृथक्करण के परिणाम टुकड़ों के कोड की तुलना में पढ़ना और समझना बहुत आसान है, जिसके गठन ने गैर-मानक तंत्र का उपयोग किया जो केवल एक निश्चित बंडलर में उपयोग किया जाता है।

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

 (window["webpackJsonp"] = window["webpackJsonp"] || []).push([["import1"],{ /***/ "tLzr": /*!*********************************!*\  !*** ./app/scripts/import-1.js ***!  \*********************************/ /*! exports provided: import1 */ /***/ (function(module, __webpack_exports__, __webpack_require__) { "use strict"; __webpack_require__.r(__webpack_exports__); /* harmony export (binding) */ __webpack_require__.d(__webpack_exports__, "import1", function() { return import1; }); /* harmony import */ var _dep_1__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(/*! ./dep-1 */ "6xPP"); const import1 = "imported: " + _dep_1__WEBPACK_IMPORTED_MODULE_0__["dep1"]; /***/ }) }]); 

क्या होगा अगर सैकड़ों एनपीएम निर्भरताएं हैं?

जैसा कि मैंने कहा, मेरा मानना ​​है कि पैकेज स्तर पर कोड-स्तरीय पृथक्करण आमतौर पर डेवलपर को एक अच्छी स्थिति में लाने की अनुमति देता है जब कोड पृथक्करण आक्रामक होता है, लेकिन बहुत आक्रामक नहीं होता है।

बेशक, यदि आपका एप्लिकेशन सैकड़ों विभिन्न एनपीएम पैकेजों से मॉड्यूल आयात करता है, तो आप अभी भी ऐसी स्थिति में हो सकते हैं जहां ब्राउज़र उन सभी को प्रभावी ढंग से लोड नहीं कर सकता है।

हालांकि, यदि आपके पास वास्तव में कई एनपीएम निर्भरताएं हैं, तो आपको अभी के लिए इस रणनीति को पूरी तरह से नहीं छोड़ना चाहिए। याद रखें कि आपने शायद हर पेज पर सभी npm निर्भरताएँ डाउनलोड नहीं की हैं। इसलिए, यह पता लगाना महत्वपूर्ण है कि वास्तव में कितनी निर्भरताएं लोड होती हैं।

फिर भी, मुझे यकीन है कि कुछ वास्तविक अनुप्रयोग हैं जिनकी एनपीएम निर्भरता इतनी अधिक है कि इन निर्भरताओं को अलग-अलग अंशों के रूप में प्रस्तुत नहीं किया जा सकता है। यदि आपका प्रोजेक्ट सिर्फ इतना ही है - मैं आपको सलाह दूंगा कि आप समूह पैकेज का एक तरीका खोजें, जिसमें उच्च संभावना वाले कोड को उसी समय बदल सकते हैं (जैसे react और react-dom ) क्योंकि इन पैकेजों के साथ खंड कैश react-dom को भी निष्पादित किया जाएगा। उसी समय। बाद में मैं एक उदाहरण दिखाऊंगा जिसमें सभी रिएक्ट निर्भरता को एक ही टुकड़े में वर्गीकृत किया गया है ।

जारी रखने के लिए ...

प्रिय पाठकों! आप अपनी परियोजनाओं में कोड पृथक्करण की समस्या से कैसे निपटेंगे?