Nvm-windows: مجلد التثبيت غير صحيح

هل أنا مخطئ ، أم أن NVM وضعت للتو ذاكرة تخزين مؤقت لحزمة العقدة 400 ميجابايت في ملف التعريف المتجول الخاص بي؟

كلا ، هذا خطأ في NPM.

يشير التثبيت الافتراضي إلى دليل بيانات المستخدم المحلي ، وليس إلى التجوال. في حين أنه قد يكون من الأفضل أن يكون لديك الملف القابل للتنفيذ في موقع مختلف ، فإن جميع ملفات تثبيت العقدة و npm تعتبر بيانات لـ NVM (هذا تصميم npm). مرة أخرى ، هذه الإعدادات الافتراضية لسبب ما ... يمكنك تغييرها إذا لم تعجبك.

ليس لدي أي فكرة من أين تحصل على 400 ميغا بايت منه. هل يمكنك تقديم مزيد من التفاصيل حول بيئتك؟

بالنسبة للنقطة الأولى ، ربما يكون الاختلاف هو أنني أقوم بتثبيته على جهاز كمبيوتر متصل بالمجال وأنت لست كذلك. لكن في كلتا الحالتين لا يزال خطأ. AppData مخصصة لإعدادات المستخدم ، وليست قابلة للتنفيذ.

بالنسبة للنقطة الثانية ، فإن Node نفسها هي التي ترتكب هذا الخطأ. سأبلغ عن الخطأ معهم بشكل منفصل.

هذا ليس "خطأ" بالضرورة ، ولكن إذا كان له آثار سلبية ، يسعدني النظر في حالة الاستخدام الخاصة بك. لم تكن لدي نفس التجربة مع جهاز كمبيوتر متصل بالمجال ، لذا مرة أخرى ، ستساعدني تفاصيل البيئة في فهم حالة الاستخدام المحددة الخاصة بك.

على سبيل المثال ، إذا كنت أعرف ما الذي أبحث عنه ، يمكنني جعل الإصدار التالي من المثبت مدركًا لمجال التثبيت. بمعنى آخر ، قد يكون موقع التثبيت الافتراضي أكثر ذكاءً.

فيما يلي التوصيات الأساسية:

• تذهب البرامج بـ %ProgramFiles% ، والتي عادة ما تكون C:\Program Files .
• على جهاز 64 بت ، تنتقل برامج x86 القديمة إلى %ProgramFiles(x86)% ، والتي عادة ما تكون C:\Program Files (x86) .
• تنتقل بيانات البرنامج على مستوى الجهاز ، مثل ذاكرات التخزين المؤقت للحزم ، إلى %ProgramData% ، والتي عادةً ما تكون C:\ProgramData
• إعدادات المستخدم التي يمكن أن تتجول بأمان من آلة إلى أخرى تذهب في %APPDATA%
• تنتقل إعدادات المستخدم المحلية لجهاز معين (مثل تلك التي تحتوي على مسارات تثبيت) في %LOCALAPPDATA% .

ليس من غير المألوف أن تكون الملفات التنفيذية في بيانات التطبيق. التطبيقات المثبتة باستخدام clickonce تفعل ذلك ، وهو برنامج التثبيت الذي تم إنشاؤه بواسطة Microsoft. كروم يفعل ذلك. الكثير من الأشياء تفعل ذلك.

aljones أحد الأسباب الرئيسية لهذا - قد يكون تثبيت البرامج في ملف تعريف المستخدم مناسبًا ، ولكن له بالتأكيد عواقب أمنية حيث يمكن لأي عملية تعديل الأشياء كما يحلو لها. لاحظ أن ClickOnce _does_ يتم تثبيته في ملف تعريف المستخدم ولكنه يضمن أيضًا أن تتمتع التجميعات بامتيازات أقل على النظام.

على الرغم من وجود حالات استخدام عامة لتثبيت التطبيقات لكل مستخدم دون الحاجة إلى امتيازات إدارية ، إلا أنه سلوك افتراضي ضعيف للغاية ويضع Chrome سابقة سيئة هنا ، imho.

أعتقد أن تجربتي الأخيرة ذات صلة بالمناقشة: لقد كان لدي مؤخرًا مفتاح تبديل لمحطة العمل. كانت مسارات node_packages في ملف التعريف المتجول الخاص بي عميقة جدًا ، لدرجة أن استعادة ملف التعريف المتجول الذي حاول جهازي القيام به ستفشل في كل مرة حتى أزيل مجلد node_packages. ظهرت هذه الأخطاء في سجلات أحداث Windows. بعد أن فعلت ذلك ، تمكنت محطة العمل الجديدة الخاصة بي أخيرًا من مزامنة ملفي الشخصي المتجول.

أوافق على أن التثبيت أثناء التجوال يتسبب في حدوث مشكلات عند العمل في الشركات التي تنسخ ملفك الشخصي احتياطيًا لاستخدامها داخل شبكاتها. على سبيل المثال ، يستغرق جهاز الكمبيوتر الخاص بي 30 دقيقة للإغلاق و 30 دقيقة لإعادة التشغيل ؛ كل ذلك بسبب وحدات npm. لسوء الحظ ، AFAIK ، هذه مشكلة مع NPM نفسها.

كمتابعة لهذا:

بشكل عام ، من المهم ملاحظة أن أي مدير إصدارات يقوم فقط بإدارة البرامج. أكرر تعليقًا سابقًا .... بمعنى NVM ، البرنامج المثبت (العقدة) _is_ البيانات. كيف يمكنك استخدامه (أي وحدات npm) يمكن أن تساهم في البصمة.

@ sam3k صحيح أن البصمة مرتبطة بالتأكيد بكيفية تصميم npm ، وليس هناك الكثير من NVM _should_ القيام بذلك ، ولا يوجد الكثير من npm نفسها يمكن أن تفعله لهذا الغرض. يتلخص الأمر في معرفة ما تقوم بتثبيته ، ومدير الحزم من أي نوع يجعل من السهل اعتبار ذلك أمرًا مفروغًا منه. كثير من الناس لا ينتبهون إلى أثر الوحدات ، وهي مشكلة تتعلق بجودة الكود / البيئة متأصلة في عالم المصدر المفتوح. خلاصة القول ، الأمر متروك للمجتمع لحل هذه المشكلة من خلال ممارسات الترميز المنضبطة (وهي ليست مهمة تافهة). أنا واحد من كثيرين ممن دافعوا عن هذا (انظر npm يحتاج إلى مدرب شخصي . النقطة: تتجاوز إدارة npm الفرضية الأساسية لإدارة إصدار العقدة الذي تقوم بتشغيله.

لدى كل من aljones و

لدى cokobware ما أعتقد أنه مشكلة شائعة في بيئات المؤسسات. خلاصة القول هي أن npm لم يتم تصميمه لسهولة النقل على نطاق واسع. مثيل واحد من node + npm ثقيل جدًا بالفعل ، ناهيك عن إضافة إصدارات متعددة. بغض النظر عن كيفية انتقال البيانات / الملفات من محطة العمل إلى محطة العمل ، هناك الكثير منها فقط لدرجة أن الأمر سيستغرق بعض الوقت. تتمثل الخيارات في استخدام ملفات تعريف Windows المتجولة ، أو ضغط كل شيء ونقله يدويًا ، أو إعادة التنزيل من سجل npm. بغض النظر عن كيفية قيامك بتدويرها ، فإن مزامنة محطة العمل ستستغرق وقتًا لتوصيل كل البتات في المكان الصحيح.

من المحتمل أن يظل مستقبل NVM لنظام التشغيل Windows (اعتبارًا من الآن) يركز على تبديل إصدار العقدة. قد أغير اسم المشروع ليعكس ذلك. سيستمر في تزويد المُثبِّت بالإعدادات الافتراضية الشائعة ، ولكن سيظل الأمر متروكًا للمؤسسة / المطور لتجاوز هذه الإعدادات الافتراضية بطريقة مناسبة لمؤسستهم. أرى إدارة إصدار العقدة كمشكلة مختلفة تمامًا عن إدارة بصمة npm ، على الرغم من أنني أجرب طرقًا يمكن أن توفر بها NVM4W خطافات لتحسين إدارة npm.

يرجى اتباع اقتراح Grauenwolf وهذه المراجع: دليل النشر و CSIDL ومتغيرات البيئة

• يعد الارتباط الرمزي٪ USERPROFILE٪ AppData إلى٪ PROGRAMFILES٪ أو٪ PROGRAMFILES (X86)٪ فكرة سيئة. مشكلة في تعدد المستخدمين (مشكلة ملكية. لا يمكن لمستخدم آخر الوصول إلى الرابط).
• يفترض أن يتم تخزين برنامج nvm في٪ PROGRAMFILES٪ أو٪ PROGRAMFILES (X86)٪.
• من المفترض أن يتم تخزين مستودع nodejses في٪ PROGRAMDATA٪ لأن النطاق هو جميع المستخدمين.
• من المفترض أن يتم تخزين ارتباط nodejs النشط في٪ LOCALAPPDATA٪ نظرًا لأن النطاق لكل مستخدم.

لا يمكن تثبيت NVM في٪ PROGRAMFILES٪ بسبب أخطاء أخرى. إذا قمت بوضعه في مجلد به مسافة في اسمه ، يفشل أمر التثبيت.