Nvm-windows: دعم nvmrc

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

حاولت بعض المشاريع المماثلة الأخرى استخدام ملفات .bat لإنجاز ذلك. هذا النهج هش ويتعارض مع الهدف الأساسي للهندسة المعمارية .

أنا أيضًا لا أعتقد أن الطلب واسع الانتشار على هذا.

يعد دعم .nvmrc جانبًا مهمًا إلى حد ما في استخدام NVM مع نظام CI. لا أقوم بربط اقتراح package.json ، خاصةً أنه يكسر التوافق مع nvm ، لكن هل سيتم قبول طلب سحب مع دعم .nvmrc؟

@ gruber76 - ربما لن أقبل العلاقات العامة في هذا الشأن.

.nvmrc ، package.json ... كلاهما يتطلب نفس الاختراق السيئ.

coreybutler لست متأكدًا من أنني أفهم

الاختراق السيئ

يعمل NVM لنظام التشغيل Windows عن طريق تغيير هدف الارتباط الرمزي إلى دليل تثبيت العقدة المادية المطلوب. هذا تغيير على مستوى النظام.

لنفترض أنك أطلقت نصًا برمجيًا بتحديد الإصدار 0.12.0 في ملف .nvmrc ، ثم أطلق نصًا ثانيًا بدون .nvmrc . سيشير الارتباط الرمزي إلى الإصدار 0.12.0 (من أول إنشاء مثيل). إذا كان النص الثاني يتطلب شيئًا آخر (مثل الإصدار 4.2.6) بدون .nvmrc ، فسوف يفشل. يؤدي هذا إلى عدم استقرار البيئة عند استخدام الروابط الرمزية نظرًا لعدم وجود عزل حقيقي للعملية.

الطريقة الوحيدة لعزل الإصدار حقًا على أساس كل عملية هي إعادة توجيه nvm.exe إلى الإصدار الذي يطلبه البرنامج النصي بدلاً من السماح لنظام التشغيل بالقيام بذلك. لا أريد حقًا إعادة إنشاء شيء يقوم به نظام التشغيل بالفعل بالنسبة لنا.

إذا كان الأشخاص يريدون حقًا استخدام نهج لكل عملية / مشروع ، فإن الحل الأكثر ملاءمة هو عزل بيئة وقت التشغيل. أنا شخصياً أستخدم Docker لذلك.

سامحني على جهلي هنا. حالة الاستخدام الأساسية الخاصة بي هي تطوير تطبيقات العقدة / الويب باستخدام bower / grunt / gulp ، وما إلى ذلك مع فرق متعددة. بالنسبة لي ، من النادر جدًا أن يكون لدي إصدارات متعددة تعمل في غضون خمس دقائق من بعضها البعض. بالنسبة لحالة الاستخدام هذه ، فإن ملف .nvmrc هو الطريقة التي تحدد بها فريقي ما يجب أن تفعله العقدة.

أواجه مشكلة في رؤية الموقف الذي تصفه (البرنامج النصي أ مقابل البرنامج النصي ب) كيف سيكون دعم .nvmrc أكثر إزعاجًا من استخدام البرنامج النصي A (أو مستخدم البرنامج النصي A) لاستدعاء nvm لتعيين الإصدار ثم نسيان التعيين قبل تشغيل البرنامج النصي B. ولكني أعتقد أن هناك بعض حالات الاستخدام الشائعة لـ nvm والتي تكون جوهرية أصعب بكثير من تلك الخاصة بي. ربما ، على سبيل المثال ، إذا كانت خوادم CI الخاصة بي تحتوي على حمل أثقل.

لدي حل بديل لتقديمه لأي شخص آخر يحتاجه. ما يلي في نص برمجي تم تشغيله مسبقًا:

set /p nodev=<.nvmrc
nvm install %nodev%
nvm use %nodev%

لماذا لا تضع الأمر nvm لتعيين الإصدار المطلوب في برنامج نصي npm؟

ستيف لي
مرسلة من جهازي المحمول يرجى المعذرة على أخطاء الكتابة
في 3 آذار (مارس) 2016 الساعة 16:50 ، كتب "gruber76" [email protected] :

سامحني على جهلي هنا. حالة الاستخدام الأساسية الخاصة بي تتطور
العقدة / تطبيقات الويب التي تستخدم bower / grunt / gulp ، وما إلى ذلك مع فرق متعددة. ل
أنا ، من النادر جدًا أن يكون لدي إصدارات متعددة تعمل بداخلها
خمس دقائق من بعضنا البعض. بالنسبة لحالة الاستخدام هذه ، فإن ملف .nvmrc هو كيفية استخدام ملف
تحدد الفرق ما يجب أن تفعله العقدة.

أواجه مشكلة في رؤية الموقف الذي تصفه (السيناريو أ مقابل
النصي B) كيف أن دعم .nvmrc سيكون أكثر إزعاجًا من وجود ملفات
البرنامج النصي A (أو مستخدم البرنامج النصي A) يستدعي nvm لتعيين الإصدار ثم
نسيت تعيينه قبل تشغيل البرنامج النصي B. ولكني أعتقد أن هناك
بعض حالات الاستخدام الشائعة لـ nvm التي تكون جوهرية أصعب بكثير من تلك الخاصة بي.
ربما ، على سبيل المثال ، إذا كانت خوادم CI الخاصة بي تحتوي على حمل أثقل.

لدي حل بديل لتقديمه لأي شخص آخر يحتاجه. ال
ما يلي في نص برمجي تم تشغيله مسبقًا:

تعيين / p nodev = <. nvmrc
تثبيت nvm٪ nodev٪
استخدام nvm٪ nodev٪

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/coreybutler/nvm-windows/issues/128#issuecomment -191852401
.

سيكون دعم ملف .nvmrc مفيدًا حقًا. لدينا العديد من المشاريع ، ولا تشغل جميعها نفس إصدار العقدة. الملف .nvmrc موجود في جذر كل ريبو للتأكد من استخدام الإصدار الصحيح من العقدة لمشروع معين.

كملاحظة جانبية ، من المزعج أيضًا أن يتبع nvm install بـ nvm use . أشعر بالفضول لمعرفة السبب وراء طلب الخطوة الثانية بعد التثبيت. أستطيع أن أرى كيف أن التثبيت والاستخدام هما شيئان مختلفان ، لكنني أتساءل عما إذا كانت هناك حالة استخدام حيث يقوم شخص ما بالتنزيل والتثبيت ، ولكن لا يستخدم.

حلنا لهذا هو أن لدينا ملفًا باسم install-node.js يعيش في جذر كل مشروع. عندما ننتقل إلى مشروع ، نقوم بتشغيل node install-node من سطر الأوامر. محتويات ملف install-node.js هي كما يلي:

var childProcess = require('child_process')
var fs = require('fs')

var nodeVersion = fs.readFileSync('.nvmrc', 'utf8').trim()

var command = "nvm install " + nodeVersion + " && nvm use " + nodeVersion
console.log('executing command: ' + command)
childProcess.exec(command, function(error, stdout, stderr) {
  if (stdout) console.log(stdout.toString())
  if (stderr) console.error(stderr.toString())
  if (error) console.error(error)
})

@ josh-egan-ps - كان الفصل بين install و use في الغالب لتهيئة البيئة الجماعية. غالبًا ما أقوم بتثبيت عدة إصدارات من العقدة قبل التقليب بينها. لكن؛ يبدو من المعقول تمامًا أن يكون لديك علامة ، مثل nvm install -u 5.9.1 للتثبيت والاستخدام تلقائيًا ... أو استخدام الإصدار تلقائيًا والحصول على علامة _لا_ استخدامه. سأفكر بالتأكيد في إضافة هذا.

للجميع - إذا كنت تحتاج حقًا إلى التبديل على أساس كل مشروع ، ففكر في وضع nvm use x.x.x && node index.js في قسم البرنامج النصي لبدء npm في الحزمة الخاصة بك. json. من أفضل الممارسات الشائعة استخدام npm start دائمًا لتشغيل تطبيق عقدة.

للجميع - إذا كنت تحتاج حقًا إلى التبديل على أساس كل مشروع ، ففكر في وضع nvm use xxx && node index.js في قسم البرنامج النصي لبدء npm في package.json. من أفضل الممارسات الشائعة استخدام npm start دائمًا لتشغيل تطبيق عقدة.

قد يكون ذلك متأخرًا جدًا في حالة استخدام أي نصوص برمجية npm _build_ أثناء التثبيت والتي تعتمد على إصدار node / npm. أو أدوات أخرى مثل grunt وما إلى ذلك تعمل بغزارة قد تفشل أثناء التثبيت مع الإصدار الخاطئ من node / npm. أو استخدم إصدارًا خاطئًا يسبب مشاكل أخرى ، راجع للشغل أفترض أفضل الممارسات الأخرى المتمثلة في تثبيت _ كل شيء_ محليًا (أي ليس -g) حتى لا تكون تبعيات الإصدار مشكلة أبدًا.

لذلك من الجيد استخدام npm install لإعداد كل شيء. يمكنك بعد ذلك إضافة خطوة تثبيت مسبق لاستخدام استخدام nvm. على سبيل المثال إضافة

    "preinstall": "nvm use x.x.x",

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

قد ترغب أيضًا في إضافة خطوة بدء مسبقة بدلاً من عمليات التثبيت.

@ SteveALee - نعم ، أنت على حق ، اقتراحي السابق لن ينجح. سيكون الوقت قد فات في عملية الإطلاق بشكل موثوق.

coreybutler في النهاية ذهبت من أجل هذا

"preinstall":"nvm use 4.4.1 || echo nvm not found: check node version && pause",

ربما خيار nvm use -i x.x.x سيكون جيدًا؟ هذا هو التثبيت إذا لم يكن هناك بالفعل؟

أود أن أقترح تنفيذ جزء من هذا على الأقل:

في نظام التشغيل Linux / Mac ، في مجلد به ملف .nvmrc موجود ، يمكنني تشغيل nvm use بدون تحديد إصدار محدد ، والإصدار المثبت الذي يتطابق مع محتوى .nvmrc يحصل مفعل. إذا كان الملف يقول 8 ، فسيتم تثبيت أحدث إصدار مثبت من Node 8.

أقوم بدمج هذا على أنظمتي مع برنامج نصي يثقل كاهل cd بحيث يمكنني cd في دليل ويتم تنشيط الإصدار الصحيح من العقدة ، مع هذا البرنامج النصي في .bashrc :

# Support .nvmrc
load-nvmrc() {
  if [[ -f .nvmrc && -r .nvmrc ]]; then
    nvm use
  elif [[ $(nvm version) != $(nvm version default)  ]]; then
    echo "Reverting to nvm default version"
    nvm use default
  fi
}
# Override `cd` to auto-load correct version of Node on enterting directory.
cd() { builtin cd "$@"; 'load-nvmrc'; }

يمكن أن يعمل هذا بسهولة على Windows أيضًا ، إذا كان nvm يحترم هذه الملفات.

لن يتم تنفيذ ملف nvmrc افتراضيًا. لكن؛ تحتوي خارطة الطريق على خطة لدعم الخطاف (https://github.com/coreybutler/nvm-windows/issues/190). يمكن استخدام البرنامج النصي pre-use لتعديل الإصدار وفقًا لأي ملف يريدونه (بما في ذلك package.json أو .nvmrc أو أي شيء آخر تختاره).

نظرًا لأن هذه المشكلات تبدو وكأنها ميتة تقريبًا ، فقد حصلت على برنامج نصي Powershell حل بديل يجب أن يحاكي وظيفة "استخدام nvm" و "تثبيت nvm" إذا كان الملف .nvmrc يحتوي على إصدار عقدة مكونة من رقم واحد.

nvm install (Get-Content .nvmrc) سيعمل بشكل جيد ولكن nvm use (Get-Content .nvmrc) لن يعمل (لأنه عندما يتم تمرير إصدار من رقم واحد للتثبيت ، فإنه يقوم بتثبيت أحدث نسخة من إصدار العقدة ولكن nvm use مع يقوم رقم واحد بإلحاق ".0.0" به بدلاً من الحصول على الأحدث.

coreybutler إذا قمت بتحديث الأمر "use" في nvm.go لاستخدام نفس الكود مثل install ، فسوف يجعل هذا الإصلاح غير ضروري (على سبيل المثال):
if len(version) == 1 { version = findLatestSubVersion(version) } else { version = cleanVersion(version) }

سيستخدم البرنامج النصي التالي "قائمة nvm المتوفرة" ويقوم بتصفية القائمة لأعلى إصدار LTS يطابق إصدار ملف .nvmrc ثم استخدام nvm. إذا لم يتم تثبيته ، فسيتم تثبيت nvm ثم استخدام nvm.
((nvm use (nvm list available | Where-Object -FilterScript { $_ -like ('* ' + (Get-Content .nvmrc)) + '.*'})[0].split('|')[2].trim()) -like '*not installed*') -and (nvm install (nvm list available | Where-Object -FilterScript { $_ -like ('* ' + (Get-Content .nvmrc) + '.*') })[0].split('|')[2]) -and (nvm use (nvm list available | Where-Object -FilterScript { $_ -like ('* ' + (Get-Content .nvmrc) + '.*') })[0].split('|')[2].trim())

فقط أريد أن أطلب دعم استخدام nvm للقراءة من ملف .nvmrc. من شأنه أن يجعل تجربة تطوير العقدة الخاصة بي بين نظامي التشغيل Mac و Windows سلسة.

هل هذا مغلق لأنه تم إصلاحه أم أنه لن يتم تغييره؟

هل هناك إصدار آخر متوافق مع Windows من nvm يستخدم نفس واجهة برمجة التطبيقات مثل إصدارات * nix؟