ليس هذا ما يُقصد به ci / cleaninstall. السلوك الحالي صحيح. ما تريد استخدامه هو npm shrinkwrap .

أضفنا تحديثًا لتجنب حذف node_modules _folder_ ولكن ليس _contents_ (كما هو مطلوب في الأصل في هذا npm ci هو حذف كل شيء للبدء من قائمة نظيفة. إذا كنت تريد الاحتفاظ بوحدات node_modules القديمة ، فما تحتاجه هو npm i .

شكرا على ردودكم! عذرا لردي المتأخر. لقد ألقيت نظرة على npm shrinkwrap ولكن هل هذا مخصص للتشغيل على خادم الإنشاء الخاص بنا من أجل التكامل المستمر؟ عند تشغيل هذا الأمر ، فإنه يعيد تسمية package-lock.json إلى npm-shrinkwrap.json ولكن ما الذي يجب علي تشغيله بعد ذلك أثناء CI؟ فقط npm install للحصول على تحديث تزايدي؟ أو هل يجب أن أقوم بتشغيل npm ci ولكن هذا سيؤدي إلى حذف جميع الحزم مرة أخرى :- (ما أبحث عنه هو أمر يقوم بتحديث تزايدي ولكنه سيثبت بالضبط ما هو موجود في package-lock.json

تضمين التغريدة ما أفهمه هو أن تشغيل npm install أثناء CI سيؤدي إلى تحديث package-lock.json وهذا قد يعني أن تشغيل نفس الإصدار بعد أسبوعين سيؤدي إلى تثبيت حزم مختلفة. هل هذا غير صحيح؟

ملاحظة: اعتقدت أن npm ci كان اختصارًا للتكامل المستمر

كما هو مشار إليه هنا: https://github.com/npm/npm/issues/20104#issuecomment -403321557

يُعد السلوك الحالي مشكلة إذا كنت تستخدم npm ci داخل حاوية Docker (وهو أمر شائع جدًا للتكامل المستمر) ولديك رابط ربط على node_modules

يتسبب في الخطأ التالي:

webpack_1   | npm ERR! path /var/www/project/docker-config/webpack-dev-devmode/node_modules
webpack_1   | npm ERR! code EBUSY
webpack_1   | npm ERR! errno -16
webpack_1   | npm ERR! syscall rmdir
webpack_1   | npm ERR! EBUSY: resource busy or locked, rmdir '/var/www/project/docker-config/webpack-dev-devmode/node_modules'

مما يؤدي بعد ذلك إلى إجهاض حاوية Docker.

سيكون من الرائع أن يكون لديك علامة --no-delete أو إذا كان بإمكان npm ci حذف _contents_ node_modules لكن ليس الدليل نفسه.

ci = تثبيت نظيف

هذا متوقع. لماذا لا تستخدم npm i العادي مع ملف القفل؟

سيكون من الجميل أن يكون لديك علامة - no-delete أو إذا كان npm ci يمكنه حذف محتويات node_modules ولكن ليس الدليل نفسه.

rm -rf node_modules/* && npm i

ci = تثبيت نظيف

هذا متوقع. لماذا لا تستخدم npm العادي i مع ملف القفل؟

... بسبب: https://docs.npmjs.com/cli/ci.html

يشبه هذا الأمر npm-install ، باستثناء أنه من المفترض استخدامه في البيئات الآلية مثل منصات الاختبار والتكامل المستمر والنشر - أو أي موقف تريد فيه التأكد من قيامك بتثبيت نظيف للاعتماديات الخاصة بك. يمكن أن يكون أسرع بكثير من تثبيت npm العادي عن طريق تخطي بعض الميزات الموجهة للمستخدم. كما أنه أكثر صرامة من التثبيت العادي ، والذي يمكن أن يساعد في اكتشاف

يجعل التثبيت الأسرع ونهج اللوح النظيف هذا مثاليًا لبيئات CI مثل تلك التي ذكرتها أعلاه.

rm -rf node_modules / * && npm أنا

هذا ما أفعله الآن ، لكن انظر أعلاه للرغبة في استخدام npm ci

يبدو أنه من المعقول بالنسبة لي أن أقدم طلبًا بطلب RFC للحصول على علامة تكوين تجعل npm ci يزيل محتويات node_modules وليس الـ dir نفسه. هذه أيضًا مشكلة بالنسبة لي ، حيث قمت بإعداد Dropbox لتجاهل node_modules dir انتقائيًا ، ولكن إذا قمت بحذفه ، فسيختفي هذا الإعداد الانتقائي ، وفي المرة التالية node_modules تم إنشاؤه ، والمزامنة.

يبدو أنه من المعقول بالنسبة لي أن أقدم طلب RFC يطلب علامة تكوين تجعل npm ci يزيل _contents_ node_modules وليس dir نفسه. هذه أيضًا مشكلة بالنسبة لي ، حيث قمت بإعداد Dropbox لتجاهل node_modules dir انتقائيًا ، ولكن إذا قمت بحذفه ، فسيختفي هذا الإعداد الانتقائي ، وفي المرة التالية node_modules تم إنشاؤه ، والمزامنة.

أليس هذا أيضًا ما وصفته مشكلة أخرى ، للسماح لـ npm بإنشاء ملفات لتجاهل dir (لأضواء OSX وغيرها)؟ أعتقد أنه كان هناك أيضًا أشخاص آخرون يحتاجون إلى هذه الميزة.

ci = تثبيت نظيف

هذا متوقع. لماذا لا تستخدم npm i العادي مع ملف القفل؟

npm i سيكون رائعًا ولكن فقط إذا لم يغير ملف القفل. لقد رأيت أن package-lock.json قد تم تحديثه خلال npm i أم لا ينبغي أن يحدث ذلك؟

أنا أؤيد هذه الميزة. كما هو مذكور ، يعدل npm i package-lock.json. سيكون العلم هو الحل الأمثل.

نفس الشيء ، سيكون العلم رائعًا

أنا أؤيد هذه الميزة. كما هو مذكور ، يعدل npm i package-lock.json. سيكون العلم هو الحل الأمثل.

لماذا لا تضيف علامة لـ npm i إذن؟ لأن هذا لن يكون له معنى كبير بالنسبة لـ ci = clean install وجهة نظري.

أي جزء من "التثبيت النظيف" غير متوافق مع الحفاظ على الدليل الأصلي node_modules/ كما هو (أثناء إجراء تثبيت نظيف للمحتويات الفعلية)؟

أدرك أن CI لا تعني التكامل المستمر في هذه الحالة ؛ لكن التثبيت النظيف غالبًا ما يكون مفيدًا جدًا في بيئة التكامل المستمر ، كما توضح الوثائق.

يشبه هذا الأمر npm-install ، باستثناء أنه من المفترض استخدامه في البيئات الآلية مثل منصات الاختبار والتكامل المستمر والنشر - أو أي موقف تريد فيه التأكد من قيامك بتثبيت نظيف للاعتماديات الخاصة بك. يمكن أن يكون أسرع بكثير من تثبيت npm العادي عن طريق تخطي بعض الميزات الموجهة للمستخدم. كما أنه أكثر صرامة من التثبيت العادي ، والذي يمكن أن يساعد في اكتشاف الأخطاء أو التناقضات التي تسببها البيئات المحلية المثبتة بشكل متزايد لمعظم مستخدمي npm.

يُقصد باستخدام npm ci على وجه التحديد في البيئات الآلية ، وهذا يعني عدة مرات إعدادًا يعتمد على Docker.

يعد سلوك حذف الدليل node_module/ مزعجًا في الإعداد المستند إلى Docker ، للأسباب المذكورة في هذا الموضوع.

لذلك نحن نطلب خيارًا يجعل هذا الأمر مفيدًا للغرض المقصود والبيئة.

أنا أؤيد هذه الميزة. كما هو مذكور ، يعدل npm i package-lock.json. سيكون العلم هو الحل الأمثل.

لماذا لا تضيف علامة لـ npm i إذن؟ لأن هذا لن يكون له معنى كبير بالنسبة لـ ci = clean install وجهة نظري.

يجب أن أطرح هذا السؤال هل أي اختلافات أخرى بين npm install و npm ci إذا لم يكن كذلك ، فلماذا لا يتوفر كلا الخيارين في npm install ربما ci الاحتياجات لتصبح بعض الأسماء المستعارة مثل npm install --no-update-package-lock --clean-node-modules

يعد سلوك حذف الدليل node_module/ مزعجًا في الإعداد المستند إلى Docker ، للأسباب المذكورة في هذا الموضوع.

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

ربما يحتاج ci إلى أن يصبح اسمًا مستعارًا مثل npm install --no-update-package-lock --clean-node-modules

شخصيًا ، هذا أكثر منطقية بالنسبة لي ، أعلام إضافية للأمر العادي npm i .

أنا غير مبال بأي شيء ، وبصراحة ، هناك الكثير من n00b مع js land للحصول على حجة ملموسة بأنه يجب أن يكون ci ، كل ما أعرفه هو أنه لا يجب تحديث package-lock.json و يجب عدم إزالة node_modules

npm ci بتحديث ملف القفل ، بل يتم تثبيته من ملف القفل. تم تقديم هذا لإجراء تثبيت نظيف لأنه تم إبلاغ هؤلاء الأشخاص مسبقًا بـ rm -rf node_modules وتشغيل npm i مرة أخرى. وأراد الناس عفايك أن لا يغير ملف القفل بل يثبّت منه.

لذلك ولدت npm ci . كما أنه يتخطى بعض الأشياء مثل قائمة الحزم المثبتة والشجرة وبعض الأشياء الأخرى.

راجع https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

يغطي حالة استخدام محددة.

بالنسبة لحالات الاستخدام الأخرى ، يجب أن نضيف علامات جديدة إلى npm i حيث يمكننا أيضًا محاكاة npm ci وهو حل أكثر مرونة وأفضل من الأعلام لـ npm ci والتي يجب أن تظل تغطي فقط حالة الاستخدام الحالية imho. ما يطلبه المستخدمون هنا مشابه إلى حد ما لـ yarn install --frozen-lockfile أو yarn --frozen-lockfile .

بخلاف ذلك ، تنتشر العلامات على npm ci ، npm i وهكذا ، مما يجعل الأمر أكثر صعوبة (التوثيق ، الكود ، ...). على الأقل هذا ما أعتقده. لنضع الأمر على npm i t ، فلدينا طرق أكثر قوة ومرونة لتكوين سلوكه.

بالنسبة لحالات الاستخدام الأخرى ، يجب أن نضيف إشارات جديدة إلى npm i حيث يمكننا أيضًا محاكاة npm وهو حل أكثر مرونة وأفضل من إشارات npm ci التي يجب أن تظل تغطي فقط حالة الاستخدام الحالية imho. ما يطلبه المستخدمون هنا يشبه إلى حد ما تثبيت الغزل - ملف القفل المجمد أو ملف الغزل - الملف المجمد.

سأكون سعيدًا جدًا إذا تمت إضافة الميزة إلى npm i . هل يجب أن أقوم بتحديث المنشور الأصلي؟

npm ci بتحديث ملف القفل ، بل يتم تثبيته من ملف القفل. تم تقديم هذا لإجراء تثبيت نظيف لأنه تم إبلاغ هؤلاء الأشخاص مسبقًا بـ rm -rf node_modules وتشغيل npm i مرة أخرى. وأراد الناس عفايك أن لا يغير ملف القفل بل يثبّت منه.

لذلك ولدت npm ci . كما أنه يتخطى بعض الأشياء مثل قائمة الحزم المثبتة والشجرة وبعض الأشياء الأخرى.

راجع https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

يغطي حالة استخدام محددة.

بالنسبة لحالات الاستخدام الأخرى ، يجب أن نضيف علامات جديدة إلى npm i حيث يمكننا أيضًا محاكاة npm ci وهو حل أكثر مرونة وأفضل من الأعلام لـ npm ci والتي يجب أن تظل تغطي فقط حالة الاستخدام الحالية imho. ما يطلبه المستخدمون هنا مشابه إلى حد ما لـ yarn install --frozen-lockfile أو yarn --frozen-lockfile .

كيف يتم اعتبار rm -rf node_modules/* غير مؤهل كـ "تنظيف"؟ الميزة المطلوبة هنا تشبه إلى حد بعيد تلك الموجودة في npm ci. في رأيي ، من المنطقي إضافة علامة إلى npm ci بحيث تستخدم rm -rf node_modules/* بدلاً من rm -rf node_modules بدلاً من استيراد سلوك npm ci بالكامل إلى npm i.

راجع للشغل يجب أن تحظى هذه المشكلة بمزيد من الاهتمام ويجب على المشرفين التعبير عن آرائهم وخططهم حول ذلك ، باستخدام عامل الإرساء يتم استخدامه دائمًا بشكل أساسي في CI (التكامل المستمر) وهو أحد حالات الاستخدام الرئيسية لـ npm ci!

الرجاء فتح RFC لهذا التغيير ، بدلاً من مشكلة في هذا الريبو.

لتجنب الالتباس ، سأعيد تسمية هذه المشكلة على أنها "فارغة بدلاً من إزالة node_modules dir في npm CI"

لم تكن نيتي من هذه المشكلة حذف المجلد node_modules أو حذف محتوياته فقط. كان دائمًا ما يتم الاحتفاظ بمحتويات node_modules ولكن تأكد من أنه محدث ومتزامن مع package-lock.json . لذلك ، هناك تحديث تزايدي يلتزم بـ package-lock.json .

ربما أكون مخطئًا ولكني أشعر أن هناك مشكلتين هنا. ربما يمكن لشخص ما بدء مشكلة أخرى أو RFC حول حذف محتويات node_modules فقط بدلاً من حذف المجلد بالكامل؟ أم هل فاتني شيء؟

Zenuka السبب الكامل لكون npm CI سريع وموجود لأنه يتجاهل node_modules dir ، لذلك من غير المحتمل أن يتغير ذلك.

في حالة الاستخدام الخاصة بنا ، أعتقد أنه سيكون من الأسرع فقط التحقق مما إذا كان المجلد nodes_modules محدثًا أم لا. وإذا لم يكن الأمر كذلك ، فقم فقط بتحديث الحزم التي يجب تحديثها (مثل npm i ) لدي بعض الأجهزة الافتراضية المخصصة التي تعمل كوكلاء بناء ، لذا فإنني أقوم بتشغيل بناء والاحتفاظ بالمجلد nodes_modules وجميع محتوياته يجب أن يكون أسرع ثم حذف كل شيء وإعادة تثبيته. نحن نجري بنائنا واختباراتنا للتغييرات البرمجية أكثر بكثير من التغييرات التي تم إجراؤها على package.json أو package-lock.json .

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

حسنًا ، هذا (حساب شجرة الحزمة) هو ما يستغرق معظم الوقت. هذا الشيك سيجعل npm ci بطيئًا حقًا.

تشغيل إصدار والاحتفاظ بالمجلد nodes_modules وجميع محتوياته يجب أن يكون أسرع ثم حذف كل شيء وإعادة تثبيته.

ربما لا ، لهذا السبب تم تقديم npm ci والذي يتخطى ما يفعله npm i (راجع شجرة الحزمة).

Zenuka npm install هي بالفعل أسرع طريقة ممكنة لفعل ما تريد. npm ci له غرض واحد فقط: القيام بذلك بشكل أسرع ، عن طريق حذف node_modules حتى لا تضطر إلى حساب فرق.

ربما لا ، لهذا السبب تم تقديم npm ci الذي يتخطى ما أفعله npm (راجع شجرة الحزمة).

لقد اختبرت هذا فقط على جهازي (وهو بالطبع ليس مقياسًا جيدًا) ولكن تشغيل npm install على مجلد node_modules محدث ينتهي في غضون 10 ثوانٍ. تشغيل npm ci يستغرق دقائق. هل تتوقع نتائج مختلفة؟

أنا معجب باقتراحك بإضافة علامة لتجميد ملف القفل بـ npm install .

التحقق من وجود ما في package-lock.json موجود بالفعل بسرعة فائقة ، حتى على Windows. راجع https://github.com/fuzzykiller/verify-node-modules.

التحقق من عدم وجود أي شيء آخر في node_modules سيستغرق بالتأكيد وقتًا أطول قليلاً ولكن ربما لا يزال أقل من ثانية.

على هذا الأساس ، يمكن بسهولة إنشاء إصدار تزايدي من npm ci . تم بالفعل حساب الشجرة وحفظها في package-lock.json ، بعد كل شيء.

أيضًا ، السبب الوحيد لوجود npm ci هو تثبيت ما يوجد في package-lock.json . بدون التسلل إلى ترقيات مفاجئة ، مثل npm install يفعل.

فقط سنتان ، قمت شخصيًا بتحويل البنية التحتية الخاصة بنا إلى npm ci لأنني سئمت أيضًا من نشر علامة قديمة لن يلتزم npm i بملف القفل ... لذلك إذا كان الأمر خطيرًا بهذا الحجم من قضية لإضافة العلم في npm ci مستوى (التي أحصل .. في clean install في فعل ما قال به) ثم npm i REALLLLLYLYY يحتاج هذا العلم. لكنني أتذكر أنني قمت بالبحث في هذا الموضوع وكان هناك أيضًا موضوع مشكلة على npm i كان أكثر من عامين (ولا يزال مفتوحًا) حيث اقترح فريق npm أن يستخدم الأشخاص npm ci lol ... هذا هو نوعًا ما سبب تخلي الناس عن npm في الماضي وذهبوا للتو إلى الغزل.

مرة أخرى مجرد منظور مطور آخر

أضع تصويتي لإضافة إمكانية الاحتفاظ بالوحدات النمطية: heavy_plus_sign:.

+1 هنا - كما قالphyzical وfuzzykiller، وليس هناك "بقعة الحلو" بين npm install و npm ci من شأنها أن تبقي node_modules، ولكن لا يزال احترام package-lock.json وتشغيل أسرع.
فقط قم بالتشغيل بأسرع ما يمكن - ابحث عن التبعيات من قفل الحزمة الموجودة بالفعل في node_modules ، ثم قم بتثبيت كل شيء آخر مفقود .. لا ترقيات ، لا حذف.

أنا شخصياً لا يهمني أيهما ( install أو ci ) هو الذي سيحصل على هذا ، لكن كل هذا يبدو وكأنه npm install يجب أن يكون لديه فقط أعلام لكل شيء و npm ci ليس بالضرورة أن يكون أمرًا منفصلاً.

هذا أمر محبط إلى حد ما ، نظرًا لأنه تم وصف npm ci في الأصل كحل لنفس المشكلة التي تثيرها هذه المشكلة.

كان السلوك الأصلي الذي أراده عدد من الأشخاص مقابل npm install هو النظر إلى package-lock.json بدلاً من package.json . أردنا وضع علامة على npm install لتشغيل هذا السلوك. ما حصلنا عليه بدلاً من ذلك كان npm ci ، للأسباب التالية:

يصف package.json التبعيات المطلوبة لمشروعك. إذا كان ملف القفل الحالي لا يمكن أن يلبي هؤلاء ، يجب أن ينتج ملف القفل. الغرض من ملف القفل هو إنشاء تثبيت قابل للتكرار عبر أجهزة مختلفة ، وليس لإبطال package.json.

جيد جدا. npm install ليس المكان المناسب لهذا الخيار ، npm ci هو المكان المناسب. باستثناء npm ci يضيف سلوكيات إضافية (مسح المجلد node_modules ) التي تمنعه ​​من أن يكون حلاً مفيدًا للمشكلة الأصلية. والسبب في عدم وجود علامة على npm ci الآن هو:

ci = تثبيت نظيف

هذا متوقع. لماذا لا تستخدم npm العادي i مع ملف القفل؟

الذي ... بخير. لا يهمني حقًا مكان إضافة العلم. ليس لدي أي مصلحة في الفلسفة الأساسية وراء الواجهة. ولكن هل يمكن إضافة العلم في مكان ما من فضلك؟

هيك ، لن أثير اعتراضات حتى لو أراد الناس أمرًا ثالثًا منفصلاً تمامًا ، فلا يهمني كثيرًا. الشيء الوحيد الذي يهمني هو أنه بعد 3 سنوات من بدء هذه المحادثة حول احترام package-lock.json لعمليات التثبيت العادية ، لا تزال هناك طريقة للحصول على السلوك الذي كنا نطلبه في الأصل.

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

هذه هي الطريقة التي أرغب بها في العمل في عالم مثالي:

• npm install - نفس السلوك المتبع اليوم
• npm install --from-lockfile - التثبيت من ملف القفل (مثل ci يفعل)
• npm install --clean - نفس سلوك npm install لكن احذف محتوى node_modules
• npm ci - اسم مستعار لـ npm install --from-lockfile --clean

jdussouillez هذا بالضبط ما يجب أن يحدث. وقال بشكل جيد جدا! أود أن أرى هذا الحل مطبقًا.

من المحبط باستمرار مواجهة هذه المشكلة حيث يتعين علينا الاختيار بين السرعة والاتساق لخط أنابيب CI. لقد واجهت ذلك 3 أو 4 مرات لأسباب مختلفة في الشهرين الماضيين فقط.

ستكون هذه الميزة رائعة لخطوط أنابيب Azure وبنيات السحابة الأخرى.

https://docs.microsoft.com/en-us/azure/devops/pipelines/release/caching؟view=azure-devops#tip

نظرًا لأن npm ci يحذف مجلد node_modules لضمان استخدام مجموعة متسقة وقابلة للتكرار من الوحدات النمطية ، يجب تجنب التخزين المؤقت node_modules عند استدعاء npm ci.

إغلاق: كما ذكر claudiahdz ، قمنا بشحن إصلاح لهذا السلوك حيث لا يقوم npm ci بإزالة المجلد node_nodules نفسه بعد الآن ولكن محتوياته فقط (المرجع https://github.com/npm /libcipm/blob/latest/CHANGELOG.md#407-2019-10-09). تم شحن هذا في [email protected] مرة أخرى في 21 يوليو (المرجع. https://github.com/npm/cli/blob/v6/CHANGELOG.md#6147-2020-07-21) وقد حافظنا على نفس التجربة في npm@7 .

إذا كانت لديك مشكلة منفصلة مع npm ci أو أي أمر آخر ، فالرجاء استخدام أحد قوالب المشكلات الخاصة بنا لإرسال خطأ: https://github.com/npm/cli/issues/new/choose

ملاحظات جانبية ...

jdussouillez نقدر ردود الفعل ؛ فيما يتعلق بالتثبيت مباشرة من ملف القفل - يمكنك القيام بذلك اليوم باستخدام العلم --package-lock-only (على سبيل المثال npm install --package-lock-only ). فيما يتعلق بإضافة علامة --clean إلى install ، لا أشعر أن هذا يضيف قيمة كبيرة ولكن قد أكون مخطئًا. إذا كنت تشعر بشدة حيال ذلك ، فنحن نرغب في إرسال RFC على https://github.com/npm/rfcs

يبدو أن التعليق الذي أدلى به claudiahdz منذ عام تقريبًا مرتبط بالتأكد من أن سلوك npm ci هو حذف محتوى node_modules ، بدلاً من المجلد نفسه. يكون هذا مفيدًا عند تركيبه في حاوية عامل إرساء (على سبيل المثال) ، ولكنه لا يغير النتيجة النهائية - npm ci سيقوم بتنزيل جميع التبعيات من البداية.

يبدو أن استخدام npm install --package-lock-only يقوم بالعكس تمامًا لما يدور حوله الإصدار الأصلي (إذا فهمت بشكل صحيح) - سيؤدي فقط إلى تحديث الملف package-lock.json ، ولن يقوم بتنزيل أي تبعيات.

ما فهمت من القضية الأصلية، هو ضرورة أن يكون لها الخيار الذي يحصل على الحالة الراهنة لل node_modules مجلد، و package-lock.json الملف، والتنزيل فقط المطلوب حزم للحصول على node_modules إصدارات package-lock.json . لذلك سيكون أسرع بكثير من تنزيل كل شيء في كل مرة ، مع نفس النتيجة الصافية في النهاية.

أليس هذا ما يفعله دائمًا بالفعل npm install ؟

أليس هذا ما يفعله دائمًا بالفعل npm install ؟

بقدر ما أعلم -
سيحل npm install جميع التبعيات وفقًا لملف package.json (تجاهل package-lock.json ) ، قارن مع ما هو موجود حاليًا في المجلد node_modules ، وقم بتنزيل التبعيات التي يجب تنزيلها لتتناسب مع المتطلبات. سيتم أيضًا تحديث package-lock.json وفقًا لذلك.

إنه بالتأكيد لا يتجاهل ملف القفل - فهو يأخذ في الاعتبار فقط الشجرة الموجودة ، والتي لا يتجاهلها npm ci .

أنت محق أنا آسف.
تذكرت بشكل غير صحيح ، (ربما كان هذا هو السلوك في الماضي؟). لقد أجريت بعض الاختبارات باستخدام شجرة dep بسيطة ، وعندما يكون الملف package-lock.json موجودًا ، ثبّت npm i الإصدارات التي يحددها بالضبط ، ولا يغير أي شيء. كان هذا مجرد السلوك الذي كنت أبحث عنه ، لذلك أنا سعيد به. 👍
أعتذر عن النشر على قضية مغلقة.

كان طلبي الأصلي هو ما تصفه ATGardner:

ما فهمت من القضية الأصلية، هو ضرورة أن يكون لها الخيار الذي يحصل على الحالة الراهنة لل node_modules مجلد، و package-lock.json الملف، والتنزيل فقط المطلوب حزم للحصول على node_modules إصدارات package-lock.json . لذلك سيكون أسرع بكثير من تنزيل كل شيء في كل مرة ، مع نفس النتيجة الصافية في النهاية.

تجربتي مع npm install هي أنه يقوم أحيانًا بتحديث ملف package-lock.json . لقد اختبرت هذا مرة أخرى هذا الصباح مع مستودع لم أقم بتحديثه منذ فترة وقمت بتشغيل git pull و npm i . لم يقم في الواقع بتحديث أي إصدارات هذه المرة ، فقط أضاف بعض التبعيات والحزم الإضافية.

لسوء الحظ ، هذا مستودع خاص ولكن ربما شخص آخر كمستودع عام قابل للتكرار؟ عندما تكون هناك التزامات متعددة والتبديل بينها يؤدي إلى قيام npm install بتحديث package-lock.json ؟

أدرك أنه قد يكون هناك بعض أخطاء المستخدم المتضمنة عند عدم تنفيذ package-lock.json عند تحديث package.json لكن زملائي يعرفون أنه يجب عليهم تحديث package-lock.json أيضًا. سأبحث في هذا.

لم أتمكن من الحصول على بلدي مثال بسيط لديك npm i تغيير package-lock.json الملف. لكنني سأجربها أكثر.

إذا كان npm i ينتهي دائمًا بتنزيل نفس الإصدارات المحددة في package-lock.json ، مع الاحتفاظ بقدر ما يمكن من node_modules ، فلماذا سأحتاج في أي وقت إلى تشغيل npm ci ؟ ما فائدة حذف كل شيء قبل التنزيل مرة أخرى؟

راجع https://docs.npmjs.com/cli/v6/commands/npm-ci#description

أعتذر مرة أخرى لأن هذا ليس المكان المناسب لهذه المناقشة. هل هناك أي مكان آخر أفضل؟

ما زلت لا أفهم. إذا كانت حالة node_modules بعد تشغيل npm i تطابق تمامًا package-lock.json ، وكانت حالة node_modules بعد تشغيل npm ci هي نفسها تمامًا النتيجة النهائية - في جميع السيناريوهات تقريبًا ، بافتراض أن الكمبيوتر الذي تقوم بالبناء عليه يحتوي بالفعل على بعض / معظم التبعيات في المجلد ، ألن يكون npm i أسرع؟ لن يقوم فقط بتنزيل ما هو موجود بالفعل محليًا ، ويتطابق مع الإصدار المطلوب.

لماذا أفضل حذف وتنزيل كل شيء من البداية؟

لا ، لا يزال npm ci أسرع لأنه لا يتحقق من الشجرة مرة أخرى ، لم يتم الانتهاء من بعض مخرجات وحدة التحكم.

لماذا أفضل حذف وتنزيل كل شيء من البداية؟

لمنع المشكلات و ci مخصص لبيئات معينة مثل عمليات النشر.
أعتقد أن المستندات ذكرت الاختلافات بالفعل.

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

راجع أيضًا https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

npm ci أسرع.

لذلك عند استخدام npm i ، فإن الوقت المستغرق لقراءة node_modules ، ومعرفة الحزم التي يجب تنزيلها ، يكون أكبر بكثير من الوقت الذي يستغرقه تنزيل جميع الحزم فعليًا من npm الخوادم؟ أرغب في رؤية تجربة فعلية تقيسه.

وأنا أيضًا لا أفهم هذه الفقرة -

npm ci bypasses a package’s package.json to install modules from a package’s lockfile. This ensures reproducible builds—you are getting exactly what you expect on every install.

ألم نستنتج هنا للتو أن تشغيل npm i يستخدم الإصدارات الدقيقة في الملف package-lock.json ، وحالة node_modules بعد التشغيل مطابقة للحالة التي كان عليها يكون بعد تشغيل npm ci ؟ لذلك ستكون البنيات قابلة للتكرار بنفس القدر.

تحديث:

لقد أجريت الاختبار التالي -
لقد أنشأت مشروعًا جديدًا create-react-app . بعد اكتمال التهيئة ، كان لديه package.json مع 7 تبعيات مباشرة ، و package-lock.json يحتوي على حزم 1982.
في هذه الحالة ( node_modules يحتوي على كل التبعيات) - تشغيل npm i يأخذ

real    0m2.548s
user    0m2.659s
sys     0m0.182s

عندما قمت بحذف مجلد حزمة واحد ( node_modules/babel-eslint ) ، ثم قمت بتشغيل npm i مرة أخرى ، فقد استغرق الأمر

real    0m3.295s
user    0m3.543s
sys     0m0.434s

لإعادة تنزيل التبعية المفقودة

عندما حذفت المجلد node_moduels بالكامل ، وقمت بتشغيل npm i مرة أخرى ، استغرق الأمر

real    0m16.701s
user    0m19.251s
sys     0m10.379s

عندما قمت بتشغيل npm ci ، استغرق الأمر

real    0m20.997s
user    0m23.844s
sys     0m14.857s

لم يختلف هذا كثيرًا عندما حاولت إزالة حزمة واحدة ، أو حتى حذف المجلد node_modules بالكامل يدويًا قبل المكالمة. لم يكن ذلك مفاجئًا ، نظرًا لأن npm ci يبدأ بحذف محتوى node_modules أي حال.

بعد كل شوط ، قمت بتشغيل diff -q -r node_modules_orig/ node_modules/ للتأكد من أن النتيجة مطابقة للتبعيات الأصلية. كان دائما كذلك.

في الختام - يبدو أن استخدام npm ci يستغرق حوالي 21 ثانية على جهازي ، بغض النظر عن الحالة الحالية لـ node_modules . يستغرق استخدام npm i في مشروع مستنسخ مؤخرًا (لا يوجد node_modules ) حوالي 18 ثانية ، وتشغيله على مشروع ليس له تبعيات متغيرة ( node_modules يطابق التبعيات المطلوبة ) يستغرق حوالي 3 ثوانٍ.

إذن متى يكون استخدام npm ci هو الأفضل؟ لا يبدو الأمر أسرع (على الرغم من أنه بالطبع مجرد اختبار واحد) ، والنتيجة النهائية مماثلة لـ npm i ، لذا فإن الإنشاء اللاحق سيكون موثوقًا بنفس القدر.

يُفضل npm ci عندما تحتاج إلى _Exactly_ ما هو موجود في package-lock.json ولا شيء سوى. لا يضمن npm i تثبيت ما هو موجود بالضبط في package-lock.json . هذا حسب التصميم. بينما يعد package-lock.json إدخالًا لـ npm i ، فهو أيضًا ناتج.

أعتقد أنه لم يتبق سوى عدد قليل من الحالات حيث يقوم npm i بتثبيت شيء مختلف (وبالتالي تعديل package-lock.json ) ، مثل ربما إصدارات الحزمة التي تم حذفها بشكل بسيط.

مرة أخرى عندما تم تقديم npm ci لأول مرة ، تجاهل npm i package-lock.json مباشرة أو على الأقل كان أكثر نشاطًا في تثبيت إصدارات مختلفة.

في كلتا الحالتين ، لا يهم حقًا. npm ci يكون جيدًا فقط عندما لا يكون المجلد node_modules موجودًا بعد. وإلا فإنه بطيء بشكل غير قانوني ، خاصة على Windows. لذا فإن npm i يحتاج ببساطة إلى علامة _ ضمانات_ لن يقوم بتعديل package-lock.json ويثبت بالضبط ما بداخل package-lock.json .

لا أرى أي فائدة من إجراء مزيد من المناقشة حول سبب وكيفية ذلك. إما أن نحصل عليه أو لن نحصل عليه. كما هو ، npm ci تمتص.

/تحديث:
إليك الريبو حيث سيؤدي تشغيل npm i إلى تغيير package-lock.json : https://github.com/fuzzykiller/npm-install-demo

على الرغم من أن التغييرات تقنية بطبيعتها ، إلا أنها لا تزال غير مقبولة.

فقط لأكرر بسرعة:

• يحذف npm ci دائمًا محتوى node_modules حسب التصميم ، وهو أمر غير مرغوب فيه للبنيات غير الإنتاجية لأنها بطيئة. ومع ذلك ، فإنه يستخدم إصدارات دقيقة من الحزم الموجودة في package-lock.json ، وهو أمر مرغوب فيه في مواقف متعددة.

• npm install فقط بتحديث محتويات node_modules ، وهو أمر فعال للغاية ، ولكن حسب التصميم يتجاهل محتويات package-lock.json إذا كانت أرقام الإصدارات package.json مختلفة ، وهي غير مرغوب فيه لحالات متعددة.

• npm install --package-lock-only في المستندات :

  ستعمل الوسيطة --package-lock-only فقط على تحديث package-lock.json ، بدلاً من فحص node_modules وتنزيل التبعيات.

  لا يبدو هذا مفيدًا لأي من السيناريوهات الموضحة أعلاه.

ما الذي كان يطلبه الناس خلال السنوات الثلاث الماضية:

1. أمر (في أي مكان) يتجاهل package.json و _only_ يحترم package-lock.json كمصدر نهائي للحزم التي سيتم تثبيتها.

2. لن يؤدي ذلك إلى حذف المحتويات الكاملة لـ node_modules وإعادة تنزيل كل شيء من البداية.

بقدر ما أستطيع أن أرى من كل من المستندات والاختبار المحلي ، npm install يرضي النقطة 2 ، لكن ليس 1. npm ci يرضي النقطة 1 ، لكن ليس 2. npm install --package-lock-only لا يرضي أي شيء من تلك المتطلبات.

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

تحرير: لتمديد مثالfuzzykiller ، لا يقتصر الأمر على تحديث package-lock.json . سيكون ذلك مزعجًا ، لكنه لن يكسر أيًا من بنياتي. ولكن إذا كان package.json يحتوي على تبعيات غامضة مدرجة في أي مكان ، وتم إصدار نسخة bugfix من هذه التبعيات ، فسيتم تغييرها عندما أقوم بتشغيل npm install على جهاز جديد. فجأة لدي اختلافات في التثبيت بين جهازين. لقد واجهنا أخطاء في شركتي من هذا السلوك بالضبط ، فالأمر لا يقتصر فقط على أن package-lock.json يحتاج إلى إعادة التحقق في Git مرة أخرى.

من المستحسن في هذه الحالة أن يكون لديك أمر يتصرف مثل npm ci - يقوم بإجراء تثبيت قابل للتكرار يعتمد على محتويات package-lock.json . ومع ذلك ، يؤدي حذف محتويات المجلد node_modules إلى إبطاء إنشاء الكثير جدًا لبعض البيئات والمواقف ، على الرغم من أنه السلوك المناسب لبناء الإنتاج النهائي.

يمكن أن يكون هناك علم في أي مكان لمعالجة هذه المشكلة. يمكن أن يكون npm install --from-lockfile . يمكن أن يكون npm ci --preserve-existing . ولكن في الوقت الحالي ، يبدو أننا في دائرة حيث تتم إضافة أي شخص يطلب العلم إلى npm install عند npm ci كحل ، وأي شخص يطلب العلم على npm ci عند npm install كحل. تم إغلاق هذه المشكلة بالإشارة إلى npm install --package-lock-only ، لكن هذا العلم هو عكس ما يطلبه الناس تقريبًا. لا يحترم package-lock.json كمصدر موثوق ، كما أنه لا يقوم بتحديث أو تثبيت أي من التبعيات في المجلد node_modules :)

يجب إعادة فتح هذه المشكلة.