यह वह नहीं है जो सीआई/क्लीनइंस्टॉल करने के लिए है। वर्तमान व्यवहार सही है। आप जो उपयोग करना चाहते हैं वह है npm shrinkwrap ।

हमने नोड_मॉड्यूल _फ़ोल्डर_ को हटाने से बचने के लिए एक अपडेट जोड़ा है, लेकिन इसके _contents_ को नहीं (जैसा कि मूल रूप से उस पोस्ट पर अनुरोध किया गया था)। npm ci कमांड का उद्देश्य एक साफ स्लेट से शुरू करने के लिए सब कुछ हटाना है। यदि आप अपना पुराना node_modules रखना चाहते हैं तो आपको npm i ।

आपके उत्तरों के लिए धन्यवाद! मेरे देर से उत्तर के लिए क्षमा करें। मैंने npm shrinkwrap लेकिन क्या यह निरंतर एकीकरण के लिए हमारे बिल्ड सर्वर पर चलने का इरादा है? इस कमांड को चलाते समय यह मेरे package-lock.json का नाम बदलकर npm-shrinkwrap.json लेकिन फिर मुझे CI के दौरान क्या चलाना चाहिए? केवल npm install एक वृद्धिशील अद्यतन प्राप्त करने के लिए? या मुझे npm ci चलाना चाहिए लेकिन वह सभी पैकेजों को फिर से हटा देगा :-( जो मैं खोज रहा हूं वह एक कमांड है जो एक वृद्धिशील अद्यतन करता है लेकिन हमारे package-lock.json में ठीक वही स्थापित करेगा

@claudiahdz; मैं समझता हूँ कि चल रहा है npm install सीआई दौरान अद्यतन करेगा package-lock.json और अर्थ हो सकता है कि एक ही निर्माण कुछ हफ़्ते बाद में चल रहे विभिन्न पैकेज इंस्टॉल होगा। क्या यह गलत है?

Ps मैंने सोचा था कि npm ci निरंतर एकीकरण के लिए छोटा था

जैसा कि यहां बताया गया है: https://github.com/npm/npm/issues/20104#issuecomment -403321557

वर्तमान व्यवहार समस्याग्रस्त है यदि आप डॉकर कंटेनर के अंदर npm ci का उपयोग कर रहे हैं (जो निरंतर एकीकरण के लिए काफी सामान्य है) और आपके पास 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'

जिसके परिणामस्वरूप डॉकर कंटेनर को निरस्त कर दिया जाता है।

--no-delete ध्वज होना अच्छा होगा या यदि npm ci node_modules के _contents_ को हटा सकता है लेकिन निर्देशिका स्वयं नहीं।

सीआई = क्लीन इंस्टाल

यह अपेक्षित है। आप लॉकफाइल के साथ सामान्य npm i उपयोग क्यों नहीं करते?

--no-delete फ्लैग होना अच्छा होगा या यदि npm ci नोड_मॉड्यूल्स की सामग्री को हटा सकता है, लेकिन निर्देशिका को ही नहीं।

rm -rf node_modules/* && npm i

सीआई = क्लीन इंस्टाल

यह अपेक्षित है। आप लॉकफाइल के साथ सामान्य npm i का उपयोग क्यों नहीं करते?

...क्योंकि: https://docs.npmjs.com/cli/ci.html

यह कमांड एनपीएम-इंस्टॉल के समान है, सिवाय इसके कि इसका उपयोग स्वचालित वातावरण जैसे कि परीक्षण प्लेटफॉर्म, निरंतर एकीकरण और परिनियोजन में किया जाना है - या ऐसी कोई भी स्थिति जहां आप यह सुनिश्चित करना चाहते हैं कि आप अपनी निर्भरता की एक साफ स्थापना कर रहे हैं। यह कुछ उपयोगकर्ता-उन्मुख सुविधाओं को छोड़ कर नियमित npm इंस्टॉल की तुलना में काफी तेज हो सकता है। यह एक नियमित इंस्टालेशन की तुलना में अधिक सख्त है, जो अधिकांश npm उपयोगकर्ताओं के वृद्धिशील रूप से स्थापित स्थानीय वातावरण के कारण को पकड़ने में मदद कर सकता है ।

तेजी से स्थापित और साफ स्लेट दृष्टिकोण सीआई वातावरण के लिए इसे आदर्श बनाता है जैसे कि मैंने ऊपर उल्लेख किया है।

आरएम-आरएफ नोड_मॉड्यूल/* && npm i

अब मैं यही करता हूं, लेकिन npm ci का उपयोग करने की इच्छा के लिए ऊपर देखें

मुझे एक आरएफसी फाइल करना उचित लगता है जो एक कॉन्फिग फ्लैग मांगता है जो npm ci को node_modules की सामग्री को हटा देता है न कि डीआईआर को। यह मेरे लिए भी एक मुद्दा है, इसमें मैंने ड्रॉपबॉक्स को node_modules dir को चुनिंदा रूप से अनदेखा करने के लिए सेट किया है, लेकिन अगर मैं इसे हटा देता हूं, तो वह चुनिंदा सेटिंग चली जाती है, और अगली बार node_modules बनाया गया है, यह सिंक करता है।

मुझे एक आरएफसी फाइल करने के लिए उचित लगता है जो एक कॉन्फ़िगरेशन ध्वज मांगता है जो npm ci को node_modules के _contents_ को हटा देता है न कि स्वयं डीआईआर। यह मेरे लिए भी एक मुद्दा है, इसमें मैंने ड्रॉपबॉक्स को node_modules dir को चुनिंदा रूप से अनदेखा करने के लिए सेट किया है, लेकिन अगर मैं इसे हटा देता हूं, तो वह चुनिंदा सेटिंग चली जाती है, और अगली बार node_modules बनाया गया है, यह सिंक करता है।

क्या यह भी एक और मुद्दा नहीं है, जो एनपीएम को डीआईआर (ओएसएक्स स्पॉटलाइट और अन्य के लिए) को अनदेखा करने के लिए फाइल बनाने की अनुमति देता है? मुझे लगता है कि ऐसे अन्य लोग भी थे जिन्हें इस सुविधा की आवश्यकता थी।

सीआई = क्लीन इंस्टाल

यह अपेक्षित है। आप लॉकफाइल के साथ सामान्य 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/ निर्देशिका को बरकरार रखने के साथ "क्लीन इंस्टाल" का कौन सा हिस्सा असंगत है (वास्तविक सामग्री की क्लीन इंस्टाल करते समय)?

मुझे एहसास है कि सीआई इस मामले में सतत एकीकरण के लिए खड़ा नहीं है; लेकिन एक निरंतर एकीकरण वातावरण में एक क्लीन इंस्टाल अक्सर काफी उपयोगी होता है, जैसा कि दस्तावेज़ीकरण स्पष्ट करता है।

यह कमांड एनपीएम-इंस्टॉल के समान है, सिवाय इसके कि इसका उपयोग स्वचालित वातावरण जैसे कि परीक्षण प्लेटफॉर्म, निरंतर एकीकरण और परिनियोजन में किया जाना है - या ऐसी कोई भी स्थिति जहां आप यह सुनिश्चित करना चाहते हैं कि आप अपनी निर्भरता की एक साफ स्थापना कर रहे हैं। यह कुछ उपयोगकर्ता-उन्मुख सुविधाओं को छोड़ कर नियमित npm इंस्टॉल की तुलना में काफी तेज हो सकता है। यह नियमित इंस्टालेशन की तुलना में अधिक सख्त है, जो अधिकांश npm उपयोगकर्ताओं के वृद्धिशील रूप से स्थापित स्थानीय वातावरण के कारण त्रुटियों या विसंगतियों को पकड़ने में मदद कर सकता है।

npm ci विशेष रूप से स्वचालित वातावरण में उपयोग करने के लिए है, कई बार इसका मतलब डॉकर-आधारित सेटअप है।

डॉकर-आधारित सेटअप में node_module/ निर्देशिका को हटाने का व्यवहार परेशानी भरा है, इस धागे में उल्लिखित कारणों के लिए।

इसलिए हम एक विकल्प की मांग कर रहे हैं जो इस कमांड को उसके इच्छित उद्देश्य और पर्यावरण के लिए उपयोगी बना सके।

मैं इस सुविधा का समर्थन करता हूं। जैसा कि कहा गया है, 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/ निर्देशिका को हटाने का व्यवहार परेशानी भरा है, इस धागे में उल्लिखित कारणों के लिए।

मेरी राय में यह केवल एक बार होना चाहिए जब छवि बनाई जाती है। उसके बाद विकास के दौरान npm i का उपयोग किया जाना चाहिए।

शायद ci को npm install --no-update-package-lock --clean-node-modules जैसे कुछ उपनाम बनने की जरूरत है

व्यक्तिगत रूप से यह मेरे लिए अधिक समझ में आता है, सामान्य npm i कमांड के लिए अतिरिक्त झंडे।

मैं इसके प्रति उदासीन हूं, और ईमानदारी से बहुत अधिक n00b जेएस भूमि के साथ एक ठोस तर्क है कि यह होना चाहिए ci , मुझे केवल इतना पता है कि इसे package-lock.json अपडेट नहीं करना चाहिए और node_modules को नहीं हटाना चाहिए

npm ci लॉकफाइल को अपडेट नहीं करता है, यह लॉकफाइल से इंस्टॉल होता है। इसे क्लीन इंस्टाल करने के लिए पेश किया गया था क्योंकि इससे पहले लोगों को rm -rf node_modules सलाह दी गई npm i चलाने की सलाह दी गई rm -rf node_modules । और afaik लोग चाहते थे कि यह लॉकफाइल को न बदले बल्कि इससे इंस्टाल करे।

तो 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 iwith में नए झंडे जोड़ने चाहिए, जिसके साथ हम npm ci का अनुकरण भी कर सकते हैं, जो npm ci के झंडे की तुलना में अधिक लचीला और बेहतर समाधान है, जो अभी भी केवल वर्तमान उपयोग के मामले imho को कवर करना चाहिए। उपयोगकर्ता यहां जो अनुरोध करते हैं वह यार्न इंस्टाल --फ्रोजन-लॉकफाइल या यार्न --फ्रोजन-लॉकफाइल के समान है।

मुझे बहुत खुशी होगी अगर इस सुविधा को npm i में जोड़ा गया। क्या मुझे मूल पोस्ट अपडेट करनी चाहिए?

npm ci लॉकफाइल को अपडेट नहीं करता है, यह लॉकफाइल से इंस्टॉल होता है। इसे क्लीन इंस्टाल करने के लिए पेश किया गया था क्योंकि इससे पहले लोगों को rm -rf node_modules सलाह दी गई npm i चलाने की सलाह दी गई rm -rf node_modules । और afaik लोग चाहते थे कि यह लॉकफाइल को न बदले बल्कि इससे इंस्टाल करे।

तो 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 में एक ध्वज जोड़ने के लिए अधिक समझ में आता है, इसलिए यह npm ci के संपूर्ण व्यवहार को npm i में आयात करने के बजाय rm -rf node_modules बजाय rm -rf node_modules/* का उपयोग करता है।

BTW इस मुद्दे पर अधिक ध्यान देना चाहिए और अनुरक्षकों को इसके बारे में अपनी राय और योजनाओं को आवाज देनी चाहिए, docker का उपयोग मूल रूप से हमेशा CI (निरंतर एकीकरण) में किया जाता है जो कि npm ci के मुख्य उपयोग के मामलों में से एक है!

कृपया इस रेपो में किसी समस्या के बजाय इस परिवर्तन के लिए RFC खोलें।

भ्रम से बचने के लिए, मैं इस मुद्दे का नाम बदलकर "एनपीएम सीआई में नोड_मॉड्यूल्स डीआईआर को हटाने के बजाय खाली" कर दूंगा।

इस मुद्दे का मेरा इरादा कभी भी node_modules फ़ोल्डर या केवल इसकी सामग्री को हटाना नहीं था। यह हमेशा node_modules की सामग्री को संरक्षित करने के लिए था, लेकिन सुनिश्चित करें कि यह अद्यतित है और package-lock.json साथ समन्वयित है। तो एक वृद्धिशील अद्यतन जो package-lock.json पालन ​​करता है।

शायद मैं गलत हूं लेकिन मुझे लगता है कि यहां दो मुद्दे हैं। हो सकता है कि कोई फ़ोल्डर को पूरी तरह से हटाने के बजाय केवल नोड_मॉड्यूल्स की सामग्री को हटाने के बारे में कोई अन्य मुद्दा या आरएफसी शुरू कर सके? या क्या मैं कुछ न कुछ भूल रहा हूं?

@Zenuka पूरे कारण

हमारे उपयोग के मामले में, मुझे लगता है कि यह जांचना तेज़ होगा कि 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 का केवल एक ही उद्देश्य है: नोड_मॉड्यूल्स को हटाकर इसे तेजी से करें ताकि इसे एक अंतर की गणना न करनी पड़े।

शायद नहीं, इसीलिए npm ci पेश किया गया था जो npm i क्या करता है (पैकेज ट्री की जाँच करें) को छोड़ देता है।

मैंने इसे केवल अपनी मशीन पर परीक्षण किया है (जो निश्चित रूप से एक अच्छा उपाय नहीं है) लेकिन npm install को अप-टू-डेट node_modules फ़ोल्डर पर चलाना 10 सेकंड के भीतर समाप्त होता है। npm ci चलने में कुछ मिनट लगते हैं। क्या आप विभिन्न परिणामों की अपेक्षा करेंगे?

मैं npm install साथ लॉक फ़ाइल को फ़्रीज़ करने के लिए फ़्लैग जोड़ने के आपके सुझाव का प्रशंसक हूं।

यह सत्यापित करना कि package-lock.json वह वास्तव में मौजूद है, विंडोज़ पर भी सुपर फास्ट है। https://github.com/fuzzykiller/verify-node-modules देखें

यह सत्यापित करना कि node_modules में और कुछ भी मौजूद नहीं है, निश्चित रूप से थोड़ा अधिक समय लेगा लेकिन शायद एक सेकंड से भी कम समय लगेगा।

इस आधार पर, npm ci एक वृद्धिशील संस्करण आसानी से बनाया जा सकता है। पेड़ की गणना पहले ही की जा चुकी है और package-lock.json सहेजा गया है।

इसके अलावा, मूल रूप से एकमात्र कारण npm ci मौजूद है क्या में है स्थापित करने के लिए है package-lock.json । आश्चर्यजनक उन्नयन में चुपके के बिना, जैसे npm install करता है।

बस मेरे 2 सेंट, मैंने व्यक्तिगत रूप से हमारे इंफ्रा को npm ci पर स्विच कर दिया क्योंकि मैं भी एक पुराने टैग की तैनाती पर बीमार था npm i लॉक फ़ाइल का पालन नहीं करेगा ... इसलिए यदि यह गंभीरता से है npm ci स्तर पर ध्वज जोड़ने के लिए एक बड़ा मुद्दा (जो मुझे मिलता है .. इसकी clean install यह वही कर रहा है जो उसने कहा था) तो npm i REALLLLLYY को इस ध्वज की आवश्यकता है। लेकिन मुझे इस पर शोध करना याद है और npm i पर एक मुद्दा धागा भी था जो 2 साल से अधिक पुराना था (और अभी भी खुला है) जहां npm टीम ने लोगों को npm ci lol का उपयोग करने का सुझाव दिया था ... यह यही कारण है कि लोगों ने अतीत में npm को छोड़ दिया है और सिर्फ सूत पर चले गए हैं।

फिर से बस एक और देव परिप्रेक्ष्य

मैंने मॉड्यूल रखने की संभावना जोड़ने के लिए अपना वोट दिया :heavy_plus_sign:।

+1 यहाँ - जैसा कि @phyzical और @fuzzykiller ने कहा, npm install और npm ci बीच कोई "स्वीट स्पॉट" नहीं है जो नोड_मॉड्यूल्स को बनाए रखेगा, लेकिन फिर भी package-lock.json सम्मान करेगा और तेजी से चलेगा।
बस जितनी जल्दी हो सके दौड़ें - पैकेज-लॉक से निर्भरता की तलाश करें जो पहले से ही नोड_मॉड्यूल्स में मौजूद है, और फिर बाकी सब कुछ गायब है .. कोई अपग्रेड नहीं, कोई हटाना नहीं।

व्यक्तिगत रूप से मुझे परवाह नहीं है कि यह कौन सा है ( 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 पर झंडा नहीं होने का कारण यह है कि:

सीआई = क्लीन इंस्टाल

यह अपेक्षित है। आप लॉकफाइल के साथ सामान्य npm i का उपयोग क्यों नहीं करते?

जो... ठीक है। मुझे वास्तव में परवाह नहीं है कि झंडा कहाँ जोड़ा जाता है। इंटरफ़ेस के पीछे अंतर्निहित दर्शन में मेरी कोई हिस्सेदारी नहीं है। लेकिन क्या झंडा कृपया कहीं जोड़ा जा सकता

हेक, मैं कोई आपत्ति नहीं उठाऊंगा, भले ही लोग पूरी तरह से अलग 3 कमांड चाहते हों, मैं कम परवाह नहीं कर सकता। केवल एक चीज की मुझे परवाह है कि सामान्य इंस्टॉल के लिए package-lock.json सम्मान करने के बारे में इस बातचीत के 3 साल बाद भी व्यवहार को प्राप्त करने का कोई तरीका नहीं है जिसे हम मूल रूप से मांग रहे थे।

मेरे कार्यस्थल पर हमने पैकेज के लिए मामूली और बगफिक्स संस्करण अपडेट से बग देखे हैं। हम वास्तव में केवल उद्देश्यपूर्ण पैकेज उन्नयन के दौरान उन बगों की तलाश करना चाहते हैं, हम नहीं चाहते कि हमारे देव वातावरण हमारे उत्पादन वातावरण की तुलना में विभिन्न पैकेज संस्करणों का उपयोग कर रहे हों। वहाँ संगति बहुत महत्वपूर्ण है। कोई भी इसे कॉल करना चाहता है या जहां भी कोई इसे रखना चाहता है, हम लॉकफाइल से पैकेज प्राप्त करने का एक तेज़ तरीका चाहते हैं, जिससे हमें हर बार पहले से स्थापित मॉड्यूल के लिए node-gyp बिल्ड के माध्यम से बैठने की आवश्यकता नहीं होगी कमांड चलाओ।

इस तरह मैं चाहूंगा कि यह एक आदर्श दुनिया में काम करे:

• npm install - आज के समान व्यवहार
• npm install --from-lockfile - लॉकफाइल से इंस्टॉल करें (जैसे ci करता है)
• npm install --clean - npm install समान व्यवहार लेकिन node_modules सामग्री को हटा दें
• npm ci - npm install --from-lockfile --clean लिए एक उपनाम

@jdussouillez ठीक यही होना चाहिए। बहुत सही कहा! मुझे इस समाधान को जगह में देखना अच्छा लगेगा।

इस मुद्दे में भाग लेना लगातार निराशाजनक है जहां हमें सीआई पाइपलाइन के लिए गति और स्थिरता के बीच निर्णय लेना है। मैंने पिछले 2 महीनों में अलग-अलग कारणों से 3 या 4 बार इसमें भाग लिया है।

यह सुविधा Azure पाइपलाइन और अन्य क्लाउड आर्किटेक्चर के लिए बहुत अच्छी होगी।

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

क्योंकि npm ci यह सुनिश्चित करने के लिए नोड_मॉड्यूल फ़ोल्डर को हटा देता है कि मॉड्यूल का एक सुसंगत, दोहराने योग्य सेट का उपयोग किया जाता है, आपको npm ci को कॉल करते समय नोड_मॉड्यूल को कैशिंग करने से बचना चाहिए।

समापन: जैसा कि @claudiahdz ने उल्लेख किया है, हमने इस व्यवहार के लिए एक फिक्स भेज दिया जहां npm ci अब node_nodules फ़ोल्डर को नहीं हटाता है, लेकिन केवल इसकी सामग्री है (रेफरी। https://github.com/npm /libcipm/blob/latest/CHANGELOG.md#407-2019-10-09)। इसे 21 जुलाई को वापस [email protected] में भेज दिया गया था (संदर्भ https://github.com/npm/cli/blob/v6/CHANGELOG.md#6147-2020-07-21) और हमने इसे बनाए रखा है npm@7 में वही अनुभव।

यदि आपके पास npm ci या किसी अन्य कमांड के साथ कोई अलग समस्या है, तो कृपया बग दर्ज करने के लिए हमारे किसी एक समस्या टेम्पलेट का उपयोग करें :

साइड नोट्स...

@jdussouillez प्रतिक्रिया की सराहना करते हैं; लॉकफ़ाइल से सीधे इंस्टॉल करने के संदर्भ में - आप आज ध्वज --package-lock-only (उदा. npm install --package-lock-only ) के साथ ऐसा कर सकते हैं। --clean ध्वज को install में जोड़ने के संदर्भ में, मुझे नहीं लगता कि यह बहुत अधिक मूल्य जोड़ता है लेकिन मैं गलत हो सकता हूं। यदि आप इसके बारे में दृढ़ता से महसूस करते हैं, तो हमें खुशी होगी कि आप https://github.com/npm/rfcs पर RFC सबमिट

लगभग एक साल पहले @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 पहले से ही हमेशा करता है?

AFAIK -
npm install package.json फ़ाइल ( package-lock.json अनदेखा कर) के अनुसार सभी निर्भरताओं को हल करेगा, वर्तमान में node_modules फ़ोल्डर में जो है उससे तुलना करें, और डाउनलोड करें निर्भरताएँ जिन्हें आवश्यकताओं से मेल खाने के लिए डाउनलोड करने की आवश्यकता है। यह तदनुसार package-lock.json को भी अपडेट करेगा।

यह निश्चित रूप से लॉकफाइल को अनदेखा नहीं करता है - यह केवल मौजूदा पेड़ को ध्यान में रखता है, जो npm ci नहीं करता है।

तुम सही हो, मुझे खेद है।
मुझे गलत याद आया, (शायद अतीत में यही व्यवहार था?) बस एक साधारण डिप ट्री के साथ कुछ परीक्षण किया, और जब package-lock.json फ़ाइल मौजूद है, तो npm i ठीक उसी संस्करण को स्थापित करें जो इसे निर्दिष्ट करता है, और कुछ भी नहीं बदलता है। यह वही व्यवहार था जिसकी मुझे तलाश थी, इसलिए मैं इससे खुश हूं। मैं
एक बंद मुद्दे पर पोस्ट करने के लिए मुझे खेद है।

मेरा मूल अनुरोध वास्तव में एटीगार्डनर का वर्णन है:

मूल मुद्दे से जो मैं समझता हूं, वह एक विकल्प की आवश्यकता है जो 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 npm i बिल्कुल मेल खाती है, और 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 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 फ़ोल्डर अभी तक मौजूद नहीं है। अन्यथा यह निषेधात्मक रूप से धीमा है, खासकर विंडोज़ पर। तो npm i बस एक झंडे की जरूरत है कि _guarantees_ यह 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 डॉक्स में वर्णित है:

  --पैकेज-लॉक-ओनली तर्क नोड_मॉड्यूल की जांच करने और निर्भरता को डाउनलोड करने के बजाय केवल पैकेज-लॉक.जेसन को अपडेट करेगा।

  यह ऊपर वर्णित किसी भी परिदृश्य के लिए उपयोगी नहीं लगता है।

पिछले 3 सालों से लोग क्या मांग रहे हैं:

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 में कहीं भी अस्पष्ट निर्भरताएं सूचीबद्ध हैं, और उन निर्भरताओं का एक बगफिक्स संस्करण जारी किया जाता है, तो जब मैं एक नई मशीन पर npm install चलाऊंगा तो वे बदल जाएंगे। अचानक मैंने दो मशीनों के बीच अंतर स्थापित कर दिया है। हमने अपनी कंपनी में इस व्यवहार से बग में भाग लिया है, यह सिर्फ इतना नहीं है कि package-lock.json को फिर से गिट में जांचने की आवश्यकता है।

उस स्थिति में यह वांछनीय है कि एक आदेश है जो npm ci जैसा व्यवहार करता है - जो package-lock.json की सामग्री पर _only_ आधारित पुनरुत्पादन योग्य इंस्टॉल बनाता है। हालांकि, 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 फ़ोल्डर में किसी भी निर्भरता को अद्यतन या स्थापित नहीं करता है :)

इस मुद्दे को फिर से खोलना चाहिए।