Nvm-windows: لا يعمل مع .nvmrc

تم إنشاؤها على ٢٠ مايو ٢٠١٦  ·  8تعليقات  ·  مصدر: coreybutler/nvm-windows

بيئتي

  • [x] Windows 7 أو إصدار أقدم (غير مدعوم بالفعل بسبب EOL)
  • [ ] ويندوز 8
  • [] Windows 8.1
  • [] Windows 10
  • [] Windows 10 IoT Core
  • [] Windows Server 2012
  • [] Windows Server 2012 R2
  • [] Windows Server 2016
  • [] تثبيت Windows الخاص بي بلغة غير الإنجليزية.

    فعلت مسبقا...

  • [x] اقرأ README لتكون على دراية بمشاكل npm gotchas ومكافحة الفيروسات.

  • قام [x] بمراجعة الويكي للتأكد من أن مشكلتي لم يتم حلها بالفعل.
  • تحقق [x] من أنني أستخدم حسابًا بامتيازات إدارية.
  • [x] بحث في المشكلات (مفتوحة ومغلقة) للتأكد من أن هذه ليست مكررة.
  • تأكد [x] من أن هذا ليس سؤالًا حول كيفية استخدام NVM لنظام التشغيل Windows ، حيث يتم استخدام gitter للأسئلة والتعليقات.

    مشكلتي متعلقة بـ (حدد فقط ما ينطبق):

  • [] settings.txt

  • [] دعم الوكيل
  • [] دعم 32 أو 64 بت

    سلوك متوقع

نفس النتيجة مثل nvm use 4.4.4

السلوك الفعلي

الإخراج: node v (64-bit) is not installed.

خطوات إعادة إظهار المشكلة:

إنشاء .nvmrc ملف مع 4.4.4 كإصدار العقدة.
انتقل إلى سطر الأوامر وقم بتشغيل nvm use في نفس المجلد مثل الملف.

duplicate wontfix

التعليق الأكثر فائدة

عثرة صغيرة لهذه القضية. فقط ركضت فيه.

لا يمكن أن يكون الأمر بهذه الصعوبة. إليك ما يجب فعله إذا لم يتم توفير الإصدار لـ nvm use :

  1. خذ نسخة من .nvmrc
  2. هل هذا الإصدار مثبت؟ إن لم يكن -> قم بتثبيته
  3. هل هذا الإصدار قيد الاستخدام حاليًا؟ إن لم يكن -> استخدمه.
  4. منتهي

بمعنى آخر ، بدون تحديد رقم الإصدار ، فإن nvm use هو مزيج من nvm install < .nvmrc و nvm use < .nvmrc (أمر زائف - لن يعمل بالفعل في الوقت الحالي).

ليس هناك ما هو أكثر من ذلك بكثير.

ال 8 كومينتر

لم يتم دعم .nvmrc مطلقًا. هذه ميزة خاصة بـ nvm ، وليس NVM لنظام Windows.

coreybutler أنا من مشروع Disaster Accountability Project ولدينا بعض المطورين الذين يستخدمون windows ولا يمكنهم الاستفادة من .nvmrc . لقد بدأنا في اعتماد nvm-windows لمطوري الويب المتطوعين لدينا وأود أن تعيد النظر في دعم .nvmrc . هذا هو الموقع الذي نستخدمه .nvmrc.

@ inunotaisho26 - بشكل أساسي ، يركز هذا المشروع على إعداد Node كما لو تم تثبيته بنفس الطريقة التي سيتم بها تثبيت Node بدون مدير إصدار. يبدأ .nvmrc في الدخول في قضايا إدارة البيئة المحددة ، مما يزيد بشكل كبير من نطاق المشروع. أرى أن "إدارة البيئة" مشكلة مختلفة اختلافًا جوهريًا عن "إدارة الإصدار". لقد ناقشنا حالات الاستخدام المختلفة هذه في مجموعة عمل إدارة الإصدار .

على الرغم من أن هذه الميزة قد تم طلبها من قبل ، إلا أنها ليست شيئًا لدي وقت فراغ كافٍ لدعمه. نظرًا لعدد الأشخاص الذين يطلبون حلولًا عامة لإدارة البيئة (تتجاوز فقط .nvmrc) ، أقوم بتجربة أفكار لتطبيق إدارة البيئة التجارية لتبسيط هذه العمليات. ستتطلب متطلبات الوقت لدعم قائمة الرغبات الكبيرة للمجتمع تمويلًا أو رعاية ، لذلك من المحتمل أن أعتمد على البنية التحتية التي قمت بإنشائها بالفعل لـ

ومع ذلك ، انظر إلى خارطة الطريق . الحل "المجاني" الذي اقترحته هو نظام ربط ، مشابه لـ git pre-commit ، post-push ، إلخ. هذا من شأنه أن يسمح للمطورين بإنشاء نصوصهم الخاصة التي تساعد على بيئاتهم الفريدة. فكر في إجراءات مثل post-install ، pre-use ، pre-execute ، إلخ. هذا سيمكن المستخدمين من كتابة نص ربط يبحث عن ملف .nvmrc وتبديل الإصدار بسرعة .

coreybutler إذن ، هناك طريقتان مختلفتان لتثبيت إصدارات متعددة من العقدة ، أليس كذلك؟

نوعا ما. هناك فلسفتان مختلفتان ، لكنهما يدوران حول _ استخدام_ Node أكثر من تثبيتها.

الفلسفة 1: الاستخدام المحلي (عملية مباشرة)
العقدة نفسها لا تدعم .nvmrc . يقوم فقط بتثبيت الملف التنفيذي الخاص به و npm. يتم استخدامه _ عن طريق تشغيل node.exe مباشرة.

الفلسفة 2: الاستخدام المعزز (عملية فرعية)
.nvmrc هو اصطلاح قدمه مشروع nvm الأصلي. بدلا من استدعاء node.exe مباشرة ، فإنه يستخدم الرقائق. الرقاقة مسؤولة عن تكوين بيئة زائفة قبل تمرير الأوامر إلى العقدة القابلة للتنفيذ (على سبيل المثال ، العقدة هي عملية فرعية للرقاقة). هذا هو المكان الذي تتم فيه معالجة المنطق .nvmrc . المصيد ، خاصة على Windows ، هو أن العقدة تعمل في سياق الرقاقة ، بدلاً من سياق المستخدم. يحتوي هذا على عدد من التأثيرات / التحديات ، مثل عدم تمرير دائمًا بيانات الاعتماد المناسبة إلى العملية الفرعية للعقدة (غالبًا حول أذونات مرتفعة) ، ومتغيرات بيئة مختلفة قليلاً ، وعدم التعرف دائمًا على أقسام محرك الأقراص الثابتة (مثل D: \ drive) ، و (في بعض الحالات) تشويه مسارات الملفات (على سبيل المثال ، يتصرف __dirname بشكل غير متوقع) وما إلى ذلك. يمكن حل هذه المشكلات ، ولكن يتم دمجها عند التفكير في بيئة المؤسسة (عمليات نشر Active Directory ، أجهزة سطح المكتب المقيدة ، محركات أقراص SAN ، إلخ).

تتطلب إدارة الإصدار العامة مستوى معينًا من التعتيم من أجل منع إلغاء تثبيت / إعادة تثبيت العقدة فعليًا في كل مرة تحتاج فيها إلى تبديل إصدار (الأمر الذي قد يستغرق وقتًا طويلاً). يتماشى NVM4W مع النهج الأول باستخدام الارتباطات الرمزية لتقليص التثبيت _directory_ ، على عكس الخيار 2 ، الذي يحرك الملف القابل للتنفيذ. نتيجة لذلك ، تقوم دائمًا بتشغيل node.exe القابل للتنفيذ مباشرةً ، بدلاً من تشغيله كعملية فرعية ..

عثرة صغيرة لهذه القضية. فقط ركضت فيه.

لا يمكن أن يكون الأمر بهذه الصعوبة. إليك ما يجب فعله إذا لم يتم توفير الإصدار لـ nvm use :

  1. خذ نسخة من .nvmrc
  2. هل هذا الإصدار مثبت؟ إن لم يكن -> قم بتثبيته
  3. هل هذا الإصدار قيد الاستخدام حاليًا؟ إن لم يكن -> استخدمه.
  4. منتهي

بمعنى آخر ، بدون تحديد رقم الإصدار ، فإن nvm use هو مزيج من nvm install < .nvmrc و nvm use < .nvmrc (أمر زائف - لن يعمل بالفعل في الوقت الحالي).

ليس هناك ما هو أكثر من ذلك بكثير.

عثرة صغيرة لهذه القضية. فقط ركضت فيه.

لا يمكن أن يكون الأمر بهذه الصعوبة. إليك ما يجب فعله إذا لم يتم توفير الإصدار لـ nvm use :

1. Take version from .nvmrc

2. Is this version installed? If not -> install it

3. Is this version currently in use? If not -> use it.

4. Done

بعبارة أخرى ، بدون تحديد رقم الإصدار ، فإن nvm use هو مزيج من nvm install < .nvmrc و nvm use < .nvmrc (أمر زائف - لن يعمل بالفعل في الوقت الحالي).

ليس هناك ما هو أكثر من ذلك بكثير.

أنا سعيد لأنني لست الوحيد الذي يعاني من هذه المشكلة ...
التفكير في العودة إلى نظام لينكس للتطوير: /

thanyjeromemeichelbeck لا تتردد في مفترق المشروع وإضافة هذه الوظيفة نفسك. سأرسل رابطًا هنا عندما يكون جاهزًا.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات