Nvm-windows: गलत स्थापना फ़ोल्डर

क्या मुझसे गलती हुई है, या NVM ने मेरे रोमिंग प्रोफाइल में सिर्फ 400MB नोड पैकेज कैश डाला है?

नहीं, यह NPM में एक बग है।

डिफ़ॉल्ट स्थापना स्थानीय उपयोगकर्ता एपडेटा निर्देशिका को इंगित करती है, रोमिंग को नहीं। हालांकि एक अलग स्थान पर निष्पादन योग्य होना बेहतर हो सकता है, सभी नोड स्थापना फ़ाइलें और npm को NVM के लिए डेटा माना जाता है (यह एक npm डिज़ाइन है)। फिर, ये किसी कारण से डिफ़ॉल्ट हैं... यदि आप उन्हें पसंद नहीं करते हैं तो आप उन्हें बदल सकते हैं।

मुझे नहीं पता कि आपको 400MB कहां से मिल रहा है। क्या आप अपने पर्यावरण के बारे में अधिक जानकारी प्रदान कर सकते हैं?

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

दूसरे बिंदु के लिए, यह स्वयं नोड ही गलती कर रहा है। मैं उनके साथ अलग से एक बग फाइल करूंगा।

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

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

यहां आधारभूत सिफारिशें दी गई हैं:

• कार्यक्रम %ProgramFiles% , जो आमतौर पर C:\Program Files ।
• 64-बिट मशीन पर, पुराने x86 प्रोग्राम %ProgramFiles(x86)% , जो आमतौर पर C:\Program Files (x86) ।
• पैकेज कैश की तरह मशीन-व्यापी प्रोग्राम डेटा, %ProgramData% , जो आम तौर पर C:\ProgramData
• उपयोगकर्ता सेटिंग्स जो मशीन से मशीन में सुरक्षित रूप से घूम सकती हैं %APPDATA%
• उपयोगकर्ता सेटिंग्स जो किसी दिए गए मशीन के लिए स्थानीय हैं (उदाहरण के लिए जिसमें इंस्टॉलेशन पथ होते हैं) %LOCALAPPDATA% ।

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

@aljones एक प्रमुख कारण यह है - उपयोगकर्ता प्रोफ़ाइल में प्रोग्राम इंस्टॉल करना सुविधाजनक हो सकता है, लेकिन इसके निश्चित रूप से सुरक्षा परिणाम हैं कि कोई भी प्रक्रिया सामान को अपनी इच्छानुसार संशोधित कर सकती है। ध्यान दें कि ClickOnce _does_ यूजर प्रोफाइल में इंस्टाल करता है लेकिन यह भी सुनिश्चित करता है कि असेंबलियों के पास सिस्टम पर कम विशेषाधिकार हैं।

जबकि प्रशासनिक विशेषाधिकारों की आवश्यकता के बिना प्रति-उपयोगकर्ता एप्लिकेशन इंस्टॉल करने के लिए सामान्य उपयोग के मामले हैं, यह एक बहुत ही खराब डिफ़ॉल्ट व्यवहार है और क्रोम यहां एक खराब मिसाल कायम करता है, इम्हो।

मेरा मानना ​​​​है कि मेरा हालिया अनुभव चर्चा के लिए प्रासंगिक है: मेरे पास हाल ही में वर्कस्टेशन स्विच था। मेरी रोमिंग प्रोफ़ाइल में node_packages के लिए पथ इतने गहरे थे, कि रोमिंग प्रोफ़ाइल पुनर्स्थापित करता है कि मेरी मशीन ने हर बार विफल होने का प्रयास किया जब तक कि मैं node_packages फ़ोल्डर को नष्ट नहीं कर देता। ये त्रुटियाँ Windows इवेंट लॉग में पॉप अप हुई। ऐसा करने के बाद, मेरा नया वर्कस्टेशन आखिरकार मेरी रोमिंग प्रोफ़ाइल को सिंक कर सकता है।

मैं सहमत हूँ कि रोमिंग में स्थापित करने से समस्याएँ आती हैं जब आप उन कंपनियों पर काम करते हैं जो आपकी प्रोफ़ाइल का बैकअप अपने नेटवर्क में उपयोग करने के लिए उपयोग करती हैं। उदाहरण के लिए, मेरे कंप्यूटर को बंद होने में 30 मिनट और पुनरारंभ होने में 30 मिनट लगते हैं; सभी npm मॉड्यूल के कारण। दुर्भाग्य से, AFAIK, यह एनपीएम के साथ ही एक मुद्दा है।

इस पर एक अनुवर्ती के रूप में:

सामान्य तौर पर, यह ध्यान रखना महत्वपूर्ण है कि कोई भी संस्करण प्रबंधक केवल कार्यक्रमों का प्रबंधन कर रहा है। मैं एक पिछली टिप्पणी दोहराता हूं .... एनवीएम के अर्थ में, स्थापित प्रोग्राम (नोड) _is_ डेटा। आप इसका उपयोग कैसे करते हैं (यानी npm मॉड्यूल) पदचिह्न में योगदान कर सकते हैं।

@ sam3k सही है कि पदचिह्न निश्चित रूप से संबंधित है कि कैसे npm को नियुक्त किया गया था, और इसके लिए वास्तव में बहुत अधिक NVM _should_ नहीं है, और न ही इसके लिए बहुत अधिक npm स्वयं ही कर सकता है। यह जानने के लिए उबाल जाता है कि आप क्या स्थापित कर रहे हैं, और किसी भी प्रकार का पैकेज मैनेजर इसे आसान बनाना आसान बनाता है। बहुत से लोग मॉड्यूल के पदचिह्न पर ध्यान नहीं देते हैं, जो खुले स्रोत की दुनिया में निहित एक कोड/पर्यावरण गुणवत्ता समस्या है। निचली पंक्ति, अनुशासित कोडिंग प्रथाओं (तुच्छ कार्य से बहुत दूर) के माध्यम से इस समस्या को हल करने के लिए समुदाय पर निर्भर है। मैं उन कई लोगों में से एक हूं जिन्होंने इसकी वकालत की है (देखें npm को एक व्यक्तिगत ट्रेनर की आवश्यकता है । बिंदु: npm प्रबंधन आपके द्वारा चलाए जा रहे नोड के संस्करण के प्रबंधन के मूल आधार से परे है।

@aljones और @ygra दोनों के अच्छे अंक हैं। मैं उनसे असहमत नहीं हूं, लेकिन मैं सभी को याद दिलाना चाहता हूं कि सिम्लिंक को काम करने के लिए प्रशासनिक विशेषाधिकार एक आवश्यकता है। विंडोज़ के लिए एनवीएम कैसे काम करता है इसका मूल सिद्धांत यह है।

@cokobware में वह है जो मुझे लगता है कि उद्यम वातावरण में एक आम समस्या है। लब्बोलुआब यह है कि npm को स्केल पर आसान पोर्टेबिलिटी के लिए डिज़ाइन नहीं किया गया था। नोड + एनपीएम का एक उदाहरण पहले से ही काफी भारी है, अकेले कई संस्करणों को जोड़ने दें। डेटा/फाइलें वर्कस्टेशन से वर्कस्टेशन तक कैसे जाती हैं, इसके बावजूद, उनमें से बहुत से ऐसे हैं कि इसमें कुछ समय लगने वाला है। विकल्प हैं कि विंडोज रोमिंग प्रोफाइल का उपयोग करें, सब कुछ ज़िप करें और मैन्युअल रूप से ट्रांसफर करें, या एनपीएम रजिस्ट्री से फिर से डाउनलोड करें। कोई फर्क नहीं पड़ता कि आप इसे कैसे घुमाते हैं, वर्कस्टेशन को सिंक करने में सभी बिट्स को सही जगह पर लाने में समय लगता है।

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

कृपया @Grauenwolf सुझाव और इन संदर्भों का पालन करें: परिनियोजन मार्गदर्शिका , CSIDL और पर्यावरण चर

• सिमलिंक %USERPROFILE%AppData से %PROGRAMFILES% या %PROGRAMFILES(X86)% एक बुरा विचार है। एकाधिक उपयोगकर्ता में समस्या (स्वामित्व समस्या। अन्य उपयोगकर्ता लिंक तक नहीं पहुंच सकते हैं)।
• प्रोग्राम nvm को %PROGRAMFILES% या %PROGRAMFILES(X86)% में संग्रहित किया जाना चाहिए।
• नोडजेस रिपॉजिटरी को% PROGRAMDATA% में संग्रहित किया जाना चाहिए क्योंकि स्कोप सभी उपयोगकर्ताओं का है।
• सक्रिय नोडज लिंक को% LOCALAPPDATA% में संग्रहीत किया जाना चाहिए क्योंकि दायरा प्रति उपयोगकर्ता है।

NVM को %PROGRAMFILES% में अन्य बगों के कारण संस्थापित नहीं किया जा सकता है। यदि आप इसे किसी ऐसे फ़ोल्डर में रखते हैं जिसके नाम में एक स्थान है, तो इंस्टाल कमांड विफल हो जाता है।