क्या मैं npm 5 द्वारा बनाई गई पैकेज- lock.json फ़ाइल को कमिट करूं?

Question

npm 5 आज जारी किया गया था और नई विशेषताओं में से एक package-lock.jsonफ़ाइल के निर्माण के साथ नियतात्मक इंस्टॉल शामिल हैं ।

क्या इस फाइल को सोर्स कंट्रोल में रखा जाना चाहिए?

मैं मान रहा हूं कि यह समान है , yarn.lockऔर composer.lockदोनों को स्रोत नियंत्रण में रखा जाना चाहिए।

Comments

संक्षिप्त उत्तर: हाँ। एक टिप्पणी: जब पैकेज-लॉक.जॉन बदल जाता है तो आप उस परिवर्तन के लिए प्रतिबद्ध कर सकते हैं, अन्य स्रोत परिवर्तनों से अलग। इससे git logनिपटना आसान हो जाता है।

— पर्पलजेट 23

यदि यह मौजूद नहीं है तो एक फ़ाइल एक नियतांक स्थापित करने में मदद नहीं कर सकती है।

— एलन एच।

परियोजना पर निर्भर करता है। github.com/npm/npm/issues/20603

— गजस

यदि आप वास्तव में एनपीएम पर भरोसा करते हैं, तो उद्देश्य अधिक स्पष्ट रूप से रिपोर्ट करना है कि परियोजना क्या उपयोग कर रही है। यदि आप वास्तव में इस फाइल को अनदेखा करना चाहते हैं और इसके बजाय अपने node_modules को स्थापित करें (जवाब + टिप्पणी में .npmrc और संबंधित कॉन्फ़िगरेशन देखें) और इसका उपयोग करें कि आपके पैकेज प्रबंधक राज्यों के बजाय वास्तव में क्या बदल रहा है, इसे ट्रैक करने के लिए। अंततः: जो अधिक महत्वपूर्ण है? आपका पैकेज प्रबंधक या आपके द्वारा उपयोग किए जा रहे कोड।

— १२:15 पर jimmont

Answer 1

हाँ, package-lock.jsonस्रोत नियंत्रण में जाँच करने का इरादा है। आप NPM 5 का उपयोग कर रहे हैं, तो आप कमांड लाइन पर देख सकते हैं: created a lockfile as package-lock.json. You should commit this file.के अनुसार npm help package-lock.json:

package-lock.jsonस्वचालित रूप से किसी भी ऑपरेशन के लिए उत्पन्न होता है जहां npm या तो node_modulesपेड़ को संशोधित करता है , या package.json। यह सटीक पेड़ का वर्णन करता है जो उत्पन्न हुआ था, जैसे कि बाद में स्थापित समान पेड़ उत्पन्न करने में सक्षम हैं, चाहे मध्यवर्ती निर्भरता अपडेट की परवाह किए बिना।

यह फ़ाइल स्रोत रिपॉजिटरी में प्रतिबद्ध है , और विभिन्न उद्देश्यों के लिए काम करती है:

• निर्भरता वृक्ष के एकल प्रतिनिधित्व का वर्णन करें कि टीम के साथी, तैनाती और निरंतर एकीकरण की गारंटी एक ही निर्भरता को स्थापित करने के लिए दी जाती है।

• उपयोगकर्ताओं को " node_modulesस्वयं -यात्रा" करने की सुविधा प्रदान करें ताकि वे स्वयं निर्देशिका न कर सकें।

• पठनीय स्रोत नियंत्रण के माध्यम से वृक्ष परिवर्तनों की अधिक दृश्यता की सुविधा के लिए।

• और पहले से स्थापित पैकेजों के लिए दोहराया मेटाडेटा प्रस्तावों को छोड़ने के लिए npm की अनुमति देकर स्थापना प्रक्रिया का अनुकूलन करें।

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

यदि दोनों package-lock.jsonऔर npm-shrinkwrap.jsonएक पैकेज की जड़ में मौजूद हैं, package-lock.jsonतो पूरी तरह से नजरअंदाज कर दिया जाएगा।

Comments

यह किस तरह की परियोजनाओं में वास्तव में फ़ाइल करने के लिए सहायक है? सेमेस्टर और package.json के पूरे बिंदु यह है कि अद्यतन संगत निर्भरता को नोट करने की आवश्यकता नहीं है।

— जिज्ञासु

प्रमुख शब्द "होने की आवश्यकता नहीं है" - लेकिन व्यवहार में लोग पूरी तरह से सेमेस्टर का पालन नहीं करते हैं। इसीलिए आप पैकेज-लॉक.जॉन और पैकेज.जसन का उपयोग एक साथ कर सकते हैं ताकि पैकेजों को अपडेट करना आसान हो जाए लेकिन फिर भी यह सुनिश्चित करता है कि हर डेवलपर और हर तैनात एप्लीकेशन एक ही निर्भरता वाले पेड़ का उपयोग कर रहे हों।

— पानू होर्समलहटी

@trusktr: सिंद्रे सोरहुस "ऐप्स के लिए लॉकफाइल्स का उपयोग करने की सलाह देते हैं, लेकिन पैकेज के लिए नहीं।"

— दाख 7

एक और बात है, पैकेज-लॉक.जॉन को एनपीएम पर प्रकाशित करने के लिए नजरअंदाज कर दिया जाता है, इसलिए यदि कोई डेवलपर इसे पुस्तकालय देव के लिए उपयोग करता है, तो वे इस संभावना को कम कर रहे हैं कि वे एक अद्यतन निर्भरता संस्करण से एक प्रतिगमन पकड़ लेंगे, और इसलिए इसे पारित करेंगे अंतिम उपयोगकर्ताओं पर बग। इस कारण से, पुस्तकालय देव के लिए एक लॉक फ़ाइल का उपयोग नहीं करने से कम बग शिपिंग की संभावना बढ़ जाती है।

— trusktr

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

— स्टीफन जेड कैमिलेरी

Answer 2

हां, इसे चेक करने का इरादा है। मैं सुझाव देना चाहता हूं कि इसे अपनी अनूठी प्रतिबद्धता मिले। हम पाते हैं कि यह हमारे शोर में बहुत अंतर जोड़ता है।

Comments

यह बहस करना उचित है कि क्या इसे आपके स्रोत कोड रिपॉजिटरी में चेक किया जाना चाहिए, लेकिन इस फाइल को npm पर प्रकाशित करना वास्तव में बहस के लिए नहीं है - आपको अपने npm रजिस्ट्री में अपने पैकेज-लॉक.जॉसन या अपनी संकोचन फ़ाइल को शामिल करना होगा। यदि आप नहीं करते हैं, तो आपका प्रकाशित पैकेज आपकी पहली पीढ़ी की निर्भरता की निर्भरता के अनपेक्षित परिवर्तनों के अधीन होगा। जब तक उन 2 + पीढ़ी की निर्भरता में से एक को तोड़ने के परिवर्तन को प्रकाशित नहीं किया जाता है, और आपका प्रकाशित पैकेज रहस्यमय तरीके से टूट जाता है, तब तक आपको यह समस्या नहीं होगी। यह पैकेज- lock.json फ़ाइल उस समस्या को हल करने के लिए बनाई गई थी।

— गुरिल्लाप्रपक्षी

@BetoAveiga शोर से मेरा मतलब है कि पैकेज-लॉक के साथ कमिट करता है। जेसन में नोड पैकेज संस्करणों की इतनी सारी लाइनें हो सकती हैं, कि उस कमिट में कोई भी अन्य कार्य छिपा हुआ हो।

— xer0x

मैं आमतौर पर पैकेज इंस्टॉलेशन को अन्य काम से अलग रखता हूं। मुझे कभी भी "इंस्टाल्ड ची और मोचा" जैसी कमिटमेंट को अलग करने की जरूरत नहीं है, क्योंकि मुझे पहले से ही पता है कि क्या बदला है।

— कीथ

package-lock.jsonचड्डी और शाखा के साथ एक SCM प्रणाली पर काम करते समय फ़ाइल के बारे में कोई सलाह ? मैं एक शाखा पर कुछ बदलाव कर रहा हूं जिसे ट्रंक में विलय करने की आवश्यकता है ... क्या मुझे अब (किसी तरह) दो package-lock.jsonफाइलों के बीच संघर्ष को हल करना है ? इससे दर्द महसूस होता है।

— किमीकिलस

@guerillapresident जैसा कि मैं इसे समझता हूं, आप आंशिक रूप से सही हैं। इस फाइल को npm पर प्रकाशित करना बहस के लिए नहीं है। आप इसे प्रकाशित नहीं कर सकते।

— टिम गौटियर

Answer 3

हाँ तुम्हें करना चाहिए:

1. प्रतिबद्ध package-lock.json।
2. npm cinpm installजब आप अपने CI और अपने स्थानीय विकास मशीन दोनों पर अपने अनुप्रयोगों का निर्माण करते हैं तो इसके बजाय उपयोग करें

npm ciकार्यप्रवाह की आवश्यकता है एक के अस्तित्व package-lock.json।

---

npm installकमांड का एक बड़ा पहलू इसका अप्रत्याशित व्यवहार है जो इसे म्यूट कर सकता है package-lock.json, जबकि npm ciकेवल लॉकफ़ाइल में निर्दिष्ट संस्करणों का उपयोग करता है और अपनी त्रुटि उत्पन्न करता है

• यदि package-lock.jsonऔर package.jsonसिंक से बाहर हैं
• अगर एक package-lock.jsonलापता है।

इसलिए, npm installस्थानीय रूप से चल रहा है, esp। कई डेवलपर्स के साथ बड़ी टीमों में, इसके बजाय package-lock.jsonपूरी तरह से हटाने का फैसला करने के लिए डेवलपर्स और डेवलपर्स के भीतर बहुत सारे संघर्ष हो सकते हैं package-lock.json।

फिर भी भरोसा करने में सक्षम होने के लिए एक मजबूत उपयोग-मामला है कि परियोजना की निर्भरता अलग-अलग मशीनों में विश्वसनीय तरीके से दोहराई जाती है।

एक से package-lock.jsonआपको ठीक उसी मिलता है: एक ज्ञात करने के लिए काम राज्य।

अतीत में, मेरे पास बिना package-lock.json/ npm-shrinkwrap.json/ परियोजनाएं थीं yarn.lockजिनके निर्माण एक दिन विफल हो जाएंगे क्योंकि एक यादृच्छिक निर्भरता को ब्रेकिंग अपडेट मिला।

उन मुद्दों को हल करना मुश्किल है क्योंकि आपको कभी-कभी यह अनुमान लगाना होगा कि अंतिम कार्य संस्करण क्या था।

यदि आप एक नई निर्भरता जोड़ना चाहते हैं, तो आप अभी भी चलाते हैं npm install {dependency}। यदि आप अपग्रेड करना चाहते हैं, तो npm update {dependency}या तो उपयोग करें या npm install ${dependendency}@{version}परिवर्तित करें package-lock.json।

यदि कोई अपग्रेड विफल रहता है, तो आप अंतिम ज्ञात कार्य पर वापस लौट सकते हैं package-lock.json।

---

एनपीएम डॉक्टर को उद्धृत करने के लिए :

यह अत्यधिक अनुशंसा की जाती है कि आप उत्पन्न पैकेज लॉक को स्रोत नियंत्रण के लिए प्रतिबद्ध करें: यह आपकी टीम, आपकी तैनाती, आपके CI / निरंतर एकीकरण और किसी और को, जो सटीक पैकेज पर निर्भरता प्राप्त करने के लिए आपके पैकेज स्रोत में npm इंस्टॉल चलाता है, किसी और को भी अनुमति देगा। कि तुम विकसित कर रहे थे। इसके अतिरिक्त, इन परिवर्तनों से होने वाले अंतर मानव-पठनीय हैं और आपको आपके नोड_मॉड्यूल्स में किए गए किसी भी बदलाव के बारे में सूचित करेंगे, जिससे आप नोटिस कर सकते हैं कि क्या कोई सकरात्मक निर्भरता अद्यतन, फहराया गया था, आदि।

और बनाम के बीच अंतर केnpm cinpm install संबंध में :

• परियोजना में एक मौजूदा पैकेज-लॉक.जॉन या एनपीएम-सिक्योरव्रेप.जॉन होना चाहिए।
• यदि पैकेज लॉक में निर्भरता पैकेज में उन लोगों से मेल नहीं खाती है npm ci। पैकेज लॉक को अपडेट करने के बजाय, त्रुटि के साथ बाहर निकल जाएगा।
• npm ci केवल एक बार में पूरे प्रोजेक्ट स्थापित कर सकते हैं: इस निर्भरता के साथ व्यक्तिगत निर्भरता नहीं जोड़ी जा सकती है।
• यदि कोई node_modulesपहले से मौजूद है, तो npm ciइसकी स्थापना शुरू होने से पहले इसे स्वचालित रूप से हटा दिया जाएगा ।
• यह package.jsonपैकेज-लॉक को कभी भी नहीं लिखेगा : इंस्टॉल अनिवार्य रूप से जमे हुए हैं।

---

नोट: मैंने यहां एक समान उत्तर पोस्ट किया है

Comments

यह उत्तर अधिक क्रेडिट के योग्य है, विशेष रूप से npm ci का उपयोग करते हुए। इस समस्या का उपयोग करके अधिकांश लोगों ने पैकेज लॉक के साथ अनुभव किया है।

— जेम्सबी

मैं एक बहुत अधिक क्लीनर विकल्प होने के लिए package.json (नो कैरट या टिल्ड) में निश्चित संस्करण का उपयोग कर पाया हूं। यह मुझे इस whose build would fail one day because a random dependency got a breaking updateतरह के मुद्दे से बचाता है । हालांकि यह एक ही मुद्दे पर बच्चे की निर्भरता की संभावना को छोड़ देता है।

— अश्वनी अग्रवाल

Answer 4

हां, चेक-इन (YES, CHECK-IN) के लिए सबसे अच्छा अभ्यास है

मैं मानता हूं कि यह अंतर को देखते हुए बहुत शोर या संघर्ष पैदा करेगा। लेकिन लाभ हैं:

1. हर पैकेज के सटीक समान संस्करण की गारंटी दें । अलग-अलग समय में अलग-अलग वातावरण में निर्माण करते समय यह हिस्सा सबसे महत्वपूर्ण होता है। आप ^1.2.3अपने में उपयोग कर सकते हैं package.json, लेकिन आप यह कैसे सुनिश्चित कर सकते हैं कि हर बार npm installआपके देव मशीन और बिल्ड सर्वर में एक ही संस्करण उठाया जाएगा, विशेष रूप से उन अप्रत्यक्ष निर्भरता पैकेजों को? खैर, package-lock.jsonयह सुनिश्चित करेंगे। (जिसकी मदद से npm ciलॉक फ़ाइल के आधार पर संकुल संस्थापित करता है)
2. यह स्थापना प्रक्रिया में सुधार करता है।
3. यह नई ऑडिट सुविधा के साथ मदद करता है npm audit fix(मुझे लगता है कि ऑडिट सुविधा npm संस्करण 6 से है)।

Comments

जहां तक ​​मुझे पता है, कभी भी सेमर का उपयोग नहीं करना चाहिए (जो कि एनपीएम देवों को वैसे भी समझ में नहीं आता) कम से कम 99% मामलों में लॉकफ़ाइल होने के समान व्यवहार करना चाहिए। मेरा खुद का अनुभव है कि सेमर बकवास ज्यादातर प्राथमिक पैकेज (प्रत्यक्ष निर्भरता, भद्दा jquery खजूर, आदि) के साथ होता है। एनपीएम के साथ मेरा व्यक्तिगत अनुभव यह रहा है कि लॉक फाइलें हमेशा के लिए शोर थीं। मुझे आशा है कि यह ज्ञान हाल के संस्करणों के साथ अपरिवर्तित है।

— स्वेन्द

उल्लेख करने के लिए +1 npm ci। लोग अक्सर उल्लेख करते हैं कि package-lock.jsonपैकेजों के एक निर्धारक स्थापना की अनुमति देता है, लेकिन लगभग कभी भी उस कमांड का उल्लेख नहीं करता है जो इस व्यवहार को सुविधाजनक बनाता है! कई लोग शायद गलत तरीके से मान npm install

— लेते हैं

npm ci

— npm

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

— आदम्पास

@adampasz वास्तव में प्रत्येक देवता लॉक फाइल कर सकता है, और एक बार परीक्षण पास और मर्ज कर देने के बाद, दूसरी शाखा सिर्फ लॉक फाइल को रिन्यू करता है अगर किसी तरह से पैकेज बदल जाते हैं (हम पैकेज नहीं बदलते हैं। तो अक्सर, हम इस मुद्दे का सामना कम करते हैं (

— एक्सिन

Answer 5

मैं अपने प्रोजेक्ट्स में यह फाइल नहीं करता। क्या बात है ?

1. यह उत्पन्न होता है
2. यह gitlab में gitlab-ci.yml बिल्ड के साथ SHA1 कोड अखंडता का कारण है

हालांकि यह सच है कि मैं कभी भी अपने पैकेज में ^ का उपयोग नहीं करता हूं। क्योंकि मैं इसके साथ बुरा अनुभव करता हूं।

Comments

मेरी इच्छा है कि इसे npm डॉक्स के भीतर से और अधिक विस्तारित किया जा सकता है - यह इस बात की रूपरेखा के लिए उपयोगी होगा कि विशेष रूप से आप कमिट न करके क्या खो देते हैं package-lock.json। कुछ रिपॉजिट को इसके होने से होने वाले फायदों की आवश्यकता नहीं हो सकती है, और न ही स्रोत में कोई ऑटो-जेनरेट की गई सामग्री पसंद हो सकती है।

— आलूपरिवार

मैं देख सकता हूँ कि यह डिबगिंग के लिए कैसे उपयोगी हो सकता है (उदाहरण के लिए दो तालों के बीच एक अंतर) मुद्दों को हल करने में मदद करने के लिए। मुझे लगता है कि इसका इस्तेमाल इस तरह की चीजों को रोकने के लिए भी किया जा सकता है, लेकिन यह एक साझा रेपो में होने वाला दर्द भी हो सकता है, जहां इसके कारण मर्ज संघर्ष का अनुभव हो सकता है। शुरुआत के लिए मैं चीजों को सरल रखना चाहता हूं, मैं सिर्फ पैकेज का उपयोग करूंगा। अपने आप ही जब तक मैं देखता हूं कि पैकेज-लॉक की असली जरूरत है।

— राडेक

आप अपने package.json पर ^ का उपयोग नहीं कर सकते हैं, लेकिन आप यह सुनिश्चित कर सकते हैं कि आपकी निर्भरता इसका उपयोग न करें?

— नीकर

Answer 6

जीआईटी भिन्न होने पर शोर के बारे में शिकायत करने वाले लोगों के लिए:

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

मैंने जो किया वह एक उपनाम का उपयोग था:

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

संपूर्ण रिपॉजिटरी (इसका उपयोग करने वाले हर व्यक्ति) के लिए अलग-अलग पैकेज-लॉक को अनदेखा करने के लिए, आप इसे इसमें जोड़ सकते हैं .gitattributes:

package-lock.json binary
yarn.lock binary

इसका परिणाम यह होगा कि शो "बाइनरी फ़ाइलें a / package-lock.json और b / package-lock.json अलग-अलग होगा जब भी पैकेज लॉक फ़ाइल को बदला गया। इसके अलावा, कुछ Git सेवाएं (विशेष रूप से GitLab, लेकिन GitHub भी बाहर नहीं करेगा) इन फ़ाइलों (कोई और अधिक 10k लाइनों बदल गया है!) जब यह कर ऑनलाइन देखने से अलग है।

Comments

मैं gd() { git diff --color-words $1 $2 -- :!/yarn.lock :!/package-lock.json; }एक उपनाम के बजाय अपने .bashrc में है।

— apostl3pol

Answer 7

हां, आप इस फाइल को कर सकते हैं। से NPM की आधिकारिक डॉक्स :

package-lock.jsonस्वचालित रूप से किसी भी ऑपरेशन के लिए उत्पन्न होता है, जहां npmया तो node_modulesपेड़ को संशोधित करता है , या package.json। यह सटीक पेड़ का वर्णन करता है जो उत्पन्न हुआ था, जैसे कि बाद में स्थापित समान पेड़ उत्पन्न करने में सक्षम हैं, चाहे मध्यवर्ती निर्भरता अपडेट की परवाह किए बिना।

इस फ़ाइल को स्रोत रिपॉजिटरी [] में प्रतिबद्ध करने का इरादा है।

Comments

क्या कोई अधिष्ठापन हमेशा नोड_मॉड्यूल को अपडेट नहीं करता है, और इसलिए पैकेज-लॉक.जॉन को अपडेट करता है?

— टिम गौटियर

नहीं, आप npm ciपैकेज-लॉक से स्थापित करने के लिए चला सकते हैं। Json

— विलियम हैम्पशायर

आपको अपने उत्तर में जोर देने की आवश्यकता है कि आप अपने निरंतर एकीकरण निर्माण में npm ci का उपयोग करें यदि आपके पास रेपो पर पैकेज-लॉक.json है

— मैजिकलैम्प

Answer 8

विश्वभर में पैकेज-लॉक को बंद करें

अपने टर्मिनल में निम्नलिखित टाइप करें:

npm config set package-lock false

यह वास्तव में मेरे लिए जादू की तरह काम करता है

Comments

यह ~/.npmrcसामग्री के साथ (कम से कम मेरे macos पर) बनाता है package-lock=falseऔर उसी के साथ किसी भी विशिष्ट परियोजना में किया जा सकता है node_modules/(जैसेecho 'package-lock=false' >> .npmrc

— jimmont

यह मेरे लिए मज़ेदार है कि यह एक नकारात्मक होगा। एनपीएम समुदाय सिर्फ उस पैकेज-लॉक को स्वीकार नहीं कर सकता है। स्वचालित स्वचालित पीढ़ी खराब सामुदायिक भागीदारी थी। आपको ऐसी चीजें नहीं करनी चाहिए जो टीमों की प्रक्रिया को प्रभावित कर सकती हैं। इसे सक्षम करने का विकल्प होना चाहिए, मजबूर नहीं होना चाहिए। कितने लोग सिर्फ "git add *" करते हैं और इसे नोटिस भी नहीं करते और स्क्रू बिल्ड बनाता है। यदि आपके पास किसी प्रकार का मर्ज आधारित प्रवाह है, तो मुझे पता है कि git flow उन लोगों के लिए बाइबल की तरह है जो इसका उपयोग करते हैं, यह काम नहीं करेगा। आप मर्ज पर पीढ़ी नहीं कर सकते! एनपीएम संस्करण टूट गया है, पैकेज: 1.0.0 नियतात्मक होना चाहिए!

— एरिक ट्विलीगर

यह नीचे मतदान क्यों है? यह स्पष्ट रूप से एक सुविधा को अक्षम करने का एक कानूनी तरीका है जो काम नहीं करता है। और यद्यपि यह प्रति प्रश्न का उत्तर नहीं देता है, यह प्रश्न को लूटता है। यानी अब इसका जवाब देने की जरूरत नहीं है। मुझ से अंगूठे :)

— सुपरोल

कारण यह घट रहा है क्योंकि आप बस एक सुविधा को अक्षम कर रहे हैं।

— रज़ा

Answer 9

हां, यह पैकेज-लॉक करने के लिए एक मानक अभ्यास है

पैकेज- lock.json को कमिट करने का मुख्य कारण यह है कि प्रोजेक्ट में सभी एक ही पैकेज संस्करण पर हैं।

पेशेवरों: -

• यदि आप सख्त संस्करण का पालन करते हैं और अपने आप को तृतीय-पक्ष पैकेज में कम-असंगत परिवर्तन से खुद को बचाने के लिए प्रमुख संस्करणों को अपडेट करने की अनुमति नहीं देते हैं, तो पैकेज-लॉक करने में बहुत मदद मिलती है।
• यदि आप किसी विशेष पैकेज को अपडेट करते हैं, तो यह पैकेज-लॉक.जॉन में अपडेट हो जाता है और रिपॉजिटरी का उपयोग करने वाले सभी लोग उस विशेष संस्करण में अपडेट हो जाते हैं, जब वे आपके परिवर्तनों को खींचते हैं।

विपक्ष: -

• यह आपके पुल अनुरोधों को बदसूरत बना सकता है :) '

संपादित करें: - npm स्थापित यह सुनिश्चित नहीं करेगा कि परियोजना में सभी एक ही पैकेज संस्करण पर हैं। npm ci इससे मदद करेगा।

Comments

यदि आप npm ciइसके बजाय का उपयोग करेंगे तो विपक्ष दूर हो जाएगा npm install।

— k0pernikus

स्कोप थोड़ा रेंगना, लेकिन यहाँ @ k0pernikus की उस बेहतरीन सलाह के बारे में अधिक जानकारी दी गई है ।

— रफिन

"परियोजना में हर कोई एक ही पैकेज संस्करण पर होगा, आपको बस इतना करना है कि npm स्थापित है" नहीं सच है, आपको इसके बजाय "

— npm

धन्यवाद, @reggaeguitar इसके लिए मेरा जवाब अपडेट करना।

— निखिल मोहद्दीकर

Answer 10

Npm का मेरा उपयोग minified / uglified css / js उत्पन्न करना और django एप्लिकेशन द्वारा प्रस्तुत पृष्ठों में आवश्यक जावास्क्रिप्ट उत्पन्न करना है। मेरे अनुप्रयोगों में, जावास्क्रिप्ट एनिमेशन बनाने के लिए पृष्ठ पर चलता है, कुछ बार अजाक्स कॉल करता है, एक VUE फ्रेमवर्क के भीतर काम करता है और / या सीएसएस के साथ काम करता है। अगर पैकेज- lock.json का पैकेज में क्या है, पर कुछ ओवरराइडिंग नियंत्रण है, तो यह आवश्यक हो सकता है कि इस फ़ाइल का एक संस्करण हो। मेरे अनुभव में यह या तो उस प्रभाव को प्रभावित नहीं करता है जो npm स्थापित द्वारा स्थापित किया गया है, या यदि यह करता है, तो यह आज तक उन अनुप्रयोगों पर प्रतिकूल प्रभाव नहीं पड़ा है जो मैं अपने ज्ञान पर लागू करता हूं। मैं मोंगोडब या ऐसे अन्य अनुप्रयोगों का उपयोग नहीं करता हूं जो पारंपरिक रूप से पतले ग्राहक हैं।

मैं रेपो से पैकेज-लॉक.जॉन को हटा देता हूं क्योंकि एनपीएम इंस्टाल यह फाइल जेनरेट करता है, और एनपीएम इंस्टॉल एप को चलाने वाले प्रत्येक सर्वर पर तैनाती प्रक्रिया का हिस्सा है। नोड और एनपीएम का संस्करण नियंत्रण प्रत्येक सर्वर पर मैन्युअल रूप से किया जाता है, लेकिन मैं सावधान हूं कि वे समान हैं।

जब npm installसर्वर पर चलाया जाता है, तो यह पैकेज-लॉक.जॉन को बदल देता है, और अगर सर्वर पर रेपो द्वारा दर्ज की गई फ़ाइल में परिवर्तन होते हैं, तो अगला परिनियोजन आपको मूल से नए परिवर्तन खींचने की अनुमति देता है। इसलिए कि आप तैनात नहीं कर सकते क्योंकि पुल पैकेज-लॉक में किए गए परिवर्तनों को अधिलेखित कर देगा। json।

आप स्थानीय रूप से जनरेट किए गए पैकेज-लॉक को भी नहीं लिख सकते हैं। रेपो पर क्या है (हार्ड ओरिजिनल मास्टर को रीसेट करें) के साथ, चूंकि npm शिकायत करेगा कि क्या आप कभी भी एक कमांड जारी करते हैं अगर पैकेज-लॉक। जसन यह दर्शाता नहीं है कि क्या है npm स्थापित होने के कारण नोड_मॉड्यूल्स, इस प्रकार तैनाती को तोड़ना। अब अगर यह इंगित करता है कि नोड_मॉड्यूल्स में थोड़ा अलग संस्करण स्थापित किया गया है, तो एक बार फिर से मुझे कोई समस्या नहीं हुई है।

यदि नोड_मॉड्यूल्स आपके रेपो पर नहीं है (और यह नहीं होना चाहिए), तो पैकेज-लॉक.जॉन को नजरअंदाज किया जाना चाहिए।

अगर मुझे कुछ याद आ रहा है, तो कृपया मुझे टिप्पणियों में सही करें, लेकिन इस फ़ाइल से संस्करण को जिस बिंदु पर लिया गया है, उसका कोई मतलब नहीं है। फ़ाइल package.json में संस्करण संख्याएँ होती हैं, और मुझे लगता है कि यह फ़ाइल npm स्थापित होने पर संकुल के निर्माण के लिए प्रयोग किया जाता है, जैसे ही मैं इसे हटाता हूँ, npm संस्थापन निम्नानुसार शिकायत करता है:

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

और निर्माण विफल रहता है, हालांकि जब नोड्स / css बनाने के लिए ns_modules स्थापित करना या npm को लागू करना, पैकेज-लॉक को हटाने पर कोई शिकायत नहीं होती है।

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...

Comments

बस जोड़ने के लिए, मैंने अब अपने रिपॉजिटरी में अपने पैकेज-लॉक.जॉन को कमिट कर दिया है, और अपने ansible पर npm ci का उपयोग कर रहा हूं, जो मुझे लगता है कि डिलीट के नोड_मॉड्यूल्स को हटा देता है, और इसे अपडेट किए बिना पैकेज-लॉक.jpg में सब कुछ इंस्टॉल कर देता है। यह मेरे सामने के अंतिम आदमी को तैनाती में मैनुअल हस्तक्षेप की आवश्यकता के बिना जावास्क्रिप्ट सामान को अपग्रेड करने की अनुमति देता है।

— मैजिकलैम्प