Yarn: क्या मुझे यार्न.लॉक इन .gitignore लगाने की आवश्यकता है?

आपको अपने गिट में यार्न.लॉक जोड़ना चाहिए, इसे अनदेखा न करें।

देखें https://yarnpkg.com/en/docs/migrating-from-npm

जब आप yarn या yarn add <package> चलाते हैं, तो यार्न आपके पैकेज की मूल निर्देशिका के भीतर एक yarn.lock फ़ाइल उत्पन्न करेगा। आपको इस फ़ाइल को पढ़ने या समझने की आवश्यकता नहीं है - बस इसे स्रोत नियंत्रण में जांचें । जब अन्य लोग npm बजाय यार्न का उपयोग करना शुरू करते हैं, तो yarn.lock फ़ाइल यह सुनिश्चित करेगी कि उन्हें ठीक वैसी ही निर्भरताएँ प्राप्त हों जैसी आपके पास हैं।

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

क्या यह सही है?

@goenning
शायद यह हमेशा सबसे अच्छा विचार नहीं है कि अपने भंडार में यार्न.लॉक फ़ाइल डालें।
उदाहरण के लिए मैं सिनोपिया का उपयोग कर रहा हूं। इसलिए मेरे पास एक कस्टम npm रजिस्ट्री है। मैं मुख्य रूप से अन्य परियोजनाओं के लिए इस रजिस्ट्री का उपयोग करता हूं जहां मेरे पास निजी मॉड्यूल हैं।
लेकिन जब मैं एक सार्वजनिक परियोजना को एक git रिपॉजिटरी में धकेलता हूं, जिसमें केवल सार्वजनिक निर्भरता होती है, तो यार्न.लॉक में निर्भरता के गलत लिंक होते हैं और मेरा CI सिस्टम प्रोजेक्ट बनाने में विफल हो जाएगा।
निर्भरताएँ मेरे स्थानीय भंडार की ओर इशारा करती हैं।
यह अन्य डेवलपर्स के साथ भी हो सकता है यदि वे मेरे भंडार को क्लोन करते हैं।
क्या इसे हल करने का कोई तरीका है सिवाय यार्न.लॉक फ़ाइल को gitignore में डालने के?

इसके अलावा, यदि आपने npm रजिस्ट्री को पूर्वप्रमाणित किया है, उदाहरण के लिए myget जो npm के लिए प्रॉक्सी है, yarn.lock संकुल के लिए पूर्वप्रमाणित लिंक होंगे, जो एक प्रमुख सुरक्षा उल्लंघन है
इसे कहीं बड़े फ़ॉन्ट के साथ प्रलेखित किया जाना चाहिए।

@Pfeifenjoy क्या होगा यदि आप सबमॉड्यूल का उपयोग करके निजी पैकेज से लिंक करते हैं?
गिट का उपयोग करके, आप तैनाती कुंजी (एसएसएच के माध्यम से) का उपयोग करके रेपो तक पहुंच सकते हैं

@beenotung मैं एक निर्भरता प्रबंधक के रूप में git का उपयोग करने का बहुत बड़ा प्रशंसक नहीं हूं, क्योंकि यह बहुत धीमा है, निर्भरता को हल नहीं करता है जिस तरह से मैं उन्हें हल करना चाहता हूं और मेरी राय में एक प्रबंधक में हर निर्भरता होना सबसे अच्छा है।

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

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

संभवतः यार्न को एक उपयोगकर्ता को चेतावनी देते समय चेतावनी देनी चाहिए कि एक प्रमाणीकृत स्रोत तक पहुंच लॉक फ़ाइल में शामिल की गई है, लेकिन फिर से, यह एक सुविधा अनुरोध होगा।

@thisolivier उचित लगता है

बस एक ज्ञापन।
https://github.com/yarnpkg/yarn/issues/3330 के कारण, यदि आप चीन या अन्य प्रतिबंधित क्षेत्र में रहते हैं, और अन्य रजिस्ट्री (eq taobao) के साथ अपना मॉड्यूल बनाते हैं, तो आपको इसमें yarn.lock जोड़ना चाहिए। .gitignore करें और package-lock = false से .npmrc लिखें।

यहां मैं अपना यार्न.लॉक क्यों नहीं करता हूं: कुछ मॉड्यूल में मूल निर्भरता होती है और केवल कुछ प्लेटफॉर्म के लिए काम करेगी (प्लेटफ़ॉर्म जो ठीक उसी तरह है जहां यार्न.लॉक उत्पन्न होता है)।
अपने उपयोगकर्ताओं को खुश और बग मुक्त स्थापना रखने के लिए, मैं यार्न को हटा देता हूं - जब तक कि यार्न एक स्पष्ट दस्तावेज के साथ समाधान प्रदान नहीं करता है कि इसे कैसे हल किया जाए, तब मैं सहमत हूं।
(हमेशा डेवलपर से सच्ची कहानी सुनें)

साथ ही यह आपके कमिट्स को वास्तव में बदसूरत बनाता है।

मैं यहां सबसे अधिक वोट की गई टिप्पणी से असहमत हूं:

• यदि परियोजना का उपयोग करता है NPM, प्रतिबद्ध package-lock.json रेपो के लिए और gitignore yarn.lock
• अगर परियोजना यार्न का उपयोग करता है, के लिए प्रतिबद्ध yarn.lock रेपो के लिए और gitignore package-lock.json

यही है, आपको _not_ हमेशा रेपो को यार्न.लॉक करना चाहिए , और ओपी के प्रश्न का उत्तर देने के लिए, हां आप इसे .gitignore जोड़ना चाहेंगे।

जब अन्य लोग npm के बजाय यार्न का उपयोग करना शुरू करते हैं, तो यार्न.लॉक फ़ाइल यह सुनिश्चित करेगी कि उन्हें ठीक वैसी ही निर्भरताएँ मिले जैसी आपके पास हैं

सबसे पहले, नहीं यह नहीं होगा - केवल तभी जब आप केवल सार्वजनिक एनपीएम रजिस्ट्री का उपयोग कर रहे हों। इससे भी बदतर अगर आप यार्न में अपने निजी संगठन के लिए प्रमाणित नहीं हैं, (भले ही आप अभी भी एनपीएम में हों), और उसी नाम का एक पैकेज सार्वजनिक रजिस्ट्री में मौजूद है, तो यह बिना किसी संकेत के गलत को स्थापित कर देगा। यह भ्रमित करने वाला होगा कि आपका यार्न बिना किसी त्रुटि के क्यों स्थापित हो रहा है, फिर भी ऐप यार्न का उपयोग करते समय काम नहीं करता है, फिर भी यह npm का उपयोग करते समय करता है।

दूसरे, कई कोडबेस _don't_ यार्न का उपयोग करते हैं। यह "जब वे यार्न पर स्विच करते हैं" की बात नहीं है। मेरी लगभग सभी नोड सेवाएं और बुनियादी वेब सर्वर npm का उपयोग करते हैं और यार्न में जाने की कोई योजना नहीं है। मुझे रिएक्ट के साथ यार्न पसंद है, बस इसके बारे में।

जैसा कि @Pfeifenjoy ने ऊपर उल्लेख किया है:

मेरे पास एक कस्टम npm रजिस्ट्री है। मैं मुख्य रूप से अन्य परियोजनाओं के लिए इस रजिस्ट्री का उपयोग करता हूं जहां मेरे पास निजी मॉड्यूल हैं

लेकिन जब मैं एक सार्वजनिक परियोजना को एक git रिपॉजिटरी में धकेलता हूं, जिसमें केवल सार्वजनिक निर्भरता होती है, तो यार्न.लॉक में निर्भरता के गलत लिंक होते हैं और मेरा CI सिस्टम प्रोजेक्ट बनाने में विफल हो जाएगा।

^ एक और बात, यहां तक ​​​​कि जब आप इसे स्थानीय रूप से हल करते हैं, तो आपको समाधान को यम या सीआई के लिए जो भी कॉन्फिगरेशन में शामिल करना होता है और कहीं और आप ऐप को स्पिन करते हैं - किसी प्रकार का तर्क जो बता सकता है कि किस रजिस्ट्री का उपयोग करना है और कौन सा कमांड - कष्टप्रद और अनावश्यक लगता है

एक और बात - यदि आप सभी को हमेशा रेपो के लिए yarn.lock प्रतिबद्ध करने के लिए प्रोत्साहित करते हैं और इसे कभी भी अनदेखा नहीं करते हैं, तो डेवलपर्स रेपो में यार्न का उपयोग करना शुरू कर देंगे जो पहले से ही npm पर बहुत अधिक निर्भर करता है। यहां तक ​​​​कि उन मामलों में जहां यह ठीक काम करता है, वहां 2 लॉक फाइलों में अतिरेक होगा, और यह निर्भरता नरक का द्वार खोल देगा। और आप जानते हैं कि कुछ डेवलपर आपके योगदान ग्राफ को गड़बड़ाने वाले किसी बिंदु पर ~ 25k लाइन yarn.lock प्रतिबद्ध करेंगे: खुशी: