macOS पर किसी Node प्रोजेक्ट के इंस्टॉलेशन का आकार क्या बढ़ा रहा है, यह जानने के लिए इंस्टॉल किए गए पैकेजों को मापें, और फिर सबसे बड़े संभावित पैकेजों को npm के डिपेंडेंसी ट्री के ज़रिए ट्रेस करें। Terminal में, प्रोजेक्ट डायरेक्टरी से शुरू करें: du डिस्क उपयोग दिखाता है, npm ls इंस्टॉल किए गए ट्री को सूचीबद्ध करता है, और npm explain यह बताता है कि कोई पैकेज क्यों मौजूद है। ये अलग-अलग सवालों के जवाब देते हैं: आकार यह बताता है कि कौन जगह घेर रहा है; डिपेंडेंसी चेन यह बताती है कि उसे कौन लेकर आया।
macOS पर इंस्टॉल किए गए पैकेजों को मापें
Terminal खोलें, प्रोजेक्ट फ़ोल्डर में जाएं, और मापने से पहले यह जांचें कि उसमें node_modules मौजूद है या नहीं। निम्नलिखित कमांड macOS के डिफ़ॉल्ट zsh में काम करते हैं और शेल वाइल्डकार्ड व्यवहार पर निर्भर होने से बचाते हैं:
cd "/path/to/your/project"
ls -ld node_modules
find node_modules -mindepth 1 -maxdepth 1 -type d -prune -exec du -sh {} + | sort -h
du -sh प्रत्येक तत्काल डायरेक्टरी के लिए पढ़ने में आसान (human-readable) कुल आकार दिखाता है, और sort -h उन योगों को छोटे से बड़े क्रम में व्यवस्थित करता है। सबसे बड़ी प्रविष्टियों को देखने के लिए नीचे से पढ़ें। find कमांड प्रत्येक शीर्ष-स्तरीय डायरेक्टरी को एक बार मापता है: उदाहरण के लिए, यह node_modules/@example को एक संयुक्त स्कोप डायरेक्टरी के रूप में रिपोर्ट करता है, प्रत्येक स्कोप्ड पैकेज को अलग-अलग नहीं। यह एक उपयोगी पहला कदम है, न कि प्रत्येक डिपेंडेंसी के व्यक्तिगत रूप से उत्तरदायी आकार की रिपोर्ट।
यदि कमांड कहता है कि node_modules मौजूद नहीं है, तो हो सकता है कि प्रोजेक्ट में अभी तक कोई इंस्टॉल किया गया डिपेंडेंसी ट्री न हो, या आप गलत डायरेक्टरी में हों। केवल मापने के लिए कुछ भी इंस्टॉल करने से पहले प्रोजेक्ट के पैकेज मैनेजर और लॉकफ़ाइल की जांच करें। npm की लॉकफ़ाइल एक रिसॉल्व किए गए डिपेंडेंसी ट्री का वर्णन करती है, जबकि इंस्टॉल की गई फ़ाइलें वे हैं जिन्हें du मापता है। npm का package-lock दस्तावेज़
किसी बड़ी डायरेक्टरी को उसकी डिपेंडेंसी चेन तक ट्रेस करें
npm के लॉजिकल डिपेंडेंसी ट्री का निरीक्षण करने के लिए npm ls का उपयोग करें। इसका डिफ़ॉल्ट आउटपुट शीर्ष-स्तरीय पैकेजों पर केंद्रित होता है; --all लिस्टिंग को ट्रांजिटिव डिपेंडेंसीज़ तक विस्तारित करता है। npm ls दस्तावेज़
npm ls --all
किसी बड़े प्रोजेक्ट के लिए, पूरी लिस्टिंग बहुत भारी हो सकती है। एक बार जब आपके पास ट्री से किसी संभावित पैकेज का नाम आ जाए, तो npm से पूछें कि वह क्यों इंस्टॉल है:
npm explain package-name
package-name को वास्तविक नाम से बदलें, जैसे some-library। आउटपुट रूट प्रोजेक्ट की ओर डिपेंडेंसी चेन का अनुसरण करता है। यदि npm कई प्रतियों या संस्करणों की रिपोर्ट करता है, तो लिस्टिंग में संबंधित इंस्टॉल किए गए स्थान की पहचान करें और उस पथ को npm explain में पास करें, उदाहरण के लिए:
npm explain node_modules/parent-package/node_modules/package-name
npm किसी पैकेज के इंस्टॉल होने का कारण बनने वाली चेन को ट्रेस करने के लिए npm explain का दस्तावेज़ीकरण करता है, जिसमें डिपेंडेंसी नेस्टेड होने पर एक विशेष फ़ोल्डर भी शामिल है। npm explain दस्तावेज़
स्कोप्ड पैकेजों और नेस्टेड फ़ोल्डरों का निरीक्षण करें
पहला माप @example जैसे स्कोप को एक डायरेक्टरी में समूहित करता है। इसकी तत्काल पैकेज डायरेक्टरीज़ का निरीक्षण करने के लिए, चलाएं:
find node_modules/@example -mindepth 1 -maxdepth 1 -type d -prune -exec du -sh {} + | sort -h
@example को उस स्कोप से बदलें जो आपने पहले माप में देखा था। यदि आप किसी वेरिएबल या रिक्त स्थान (spaces) वाले पथ का उपयोग करते हैं, तो स्कोप पथ को कोट्स में रखें। अनस्कोप्ड पैकेज के लिए, उसके फ़ोल्डर को सीधे मापें, उदाहरण के लिए du -sh "node_modules/some-library"। किसी पैकेज के फ़ोल्डर में उसकी अपनी नेस्टेड डिपेंडेंसीज़ शामिल हो सकती हैं; पैरेंट और नेस्टेड डायरेक्टरी दोनों को मापने पर कुछ फ़ाइलें दो बार गिनी जाती हैं यदि आप योग को एक साथ जोड़ते हैं। इन आंकड़ों का उपयोग संभावित पैकेजों को खोजने के लिए करें, प्रत्येक ब्रांच के सटीक योगदान की गणना करने के लिए नहीं।
इसके बाद, किसी बड़े पैकेज पर या मापी गई डायरेक्टरी के अंदर दिखने वाले नेस्टेड पैकेज पथ पर npm explain चलाएं। यदि स्पष्टीकरण किसी प्रत्यक्ष डिपेंडेंसी के माध्यम से इंगित करता है, तो वह शीर्ष-स्तरीय पैकेज जांच करने योग्य ब्रांच है। एक बड़ा ट्रांजिटिव पैकेज कई ब्रांचों द्वारा साझा भी किया जा सकता है, इसलिए एक पथ के तहत इसकी उपस्थिति का अनिवार्य रूप से यह अर्थ नहीं है कि केवल वही प्रत्यक्ष डिपेंडेंसी इसका उपयोग करती है। npm npm ls को एक लॉजिकल ट्री के रूप में वर्णित करता है, जो node_modules के भौतिक लेआउट से भिन्न हो सकता है; फ़ोल्डर नेस्टिंग को पूरा ग्राफ़ मानने के बजाय संबंध को समझने के लिए स्पष्टीकरण आउटपुट का उपयोग करें।
डेवलपमेंट डिपेंडेंसीज़ को प्रोडक्शन डिपेंडेंसीज़ से अलग करें
प्रोडक्शन इंस्टॉलेशन में एक बड़ा डेवलपमेंट टूल अनावश्यक हो सकता है, जबकि एक बड़ी रनटाइम डिपेंडेंसी ऐप के लिए आवश्यक हो सकती है। चेन का निरीक्षण करें और देखें कि क्या यह npm के आउटपुट में डेवलपमेंट या प्रोडक्शन डिपेंडेंसी से जुड़ी है। यदि आप केवल-प्रोडक्शन npm इंस्टॉलेशन की तुलना करना चाहते हैं, तो npm ls --omit=dev डिस्क पर इंस्टॉलेशन व्यू से डेवलपमेंट डिपेंडेंसीज़ को छोड़ देता है; यह उन्हें package.json या लॉकफ़ाइल से नहीं हटाता है। ऑटोमेशन में ओमिशन विकल्पों का उपयोग करने से पहले npm के व्यवहार और संस्करण की पुष्टि करें। npm का install दस्तावेज़
बड़े आकार को एक संकेत मानें, न कि इस बात का प्रमाण कि कोई पैकेज अनावश्यक है। किसी डिपेंडेंसी को हटाने या बदलने से पहले यह जांच लें कि आपके एप्लिकेशन के इम्पोर्ट, बिल्ड स्क्रिप्ट और डिप्लॉयमेंट प्रक्रिया को किसकी आवश्यकता है। यदि कोई लॉकफ़ाइल मौजूद है, तो इंस्टॉल्स की तुलना करते समय इसे ध्यान में रखें: यह रिसॉल्व किए गए ट्री को रिकॉर्ड करती है और यह समझाने में मदद करती है कि कोई अन्य इंस्टॉल वर्तमान फ़ोल्डर से भिन्न क्यों हो सकता है।
एक व्यावहारिक निष्कर्ष बिंदु
आपके पास एक उपयोगी उत्तर तब होता है जब आप सबसे बड़ी मापी गई डायरेक्टरी का नाम बता सकें, उसके भीतर के पैकेज या पैकेजों की पहचान कर सकें, और उन्हें पेश करने वाली रूट डिपेंडेंसी तक ट्रेस करने के लिए npm explain का उपयोग कर सकें। यह आपको समीक्षा करने के लिए एक ठोस ब्रांच देता है। केवल डिस्क उपयोग यह तय नहीं कर सकता कि ब्रांच को हटाना सुरक्षित है या नहीं, और जब फ़ाइलें या डिपेंडेंसीज़ साझा की जाती हैं, तो npm के डिपेंडेंसी कमांड किसी पैकेज के अनन्य हिस्से की गणना नहीं करते हैं।