Yarn: `इंस्टॉल` के लिए `--pure-lockfile` को डिफ़ॉल्ट बनाएं

मैं सहमत हूं। इस बात पर चर्चा होनी चाहिए कि क्यों yarn install पहले स्थान पर डिफ़ॉल्ट रूप से लॉकफाइल लिखता है, क्योंकि यह संपूर्ण लॉकफाइल अवधारणा के साथ बाधाओं पर लगता है। लॉकफाइल क्यों है यदि यह डिफ़ॉल्ट रूप से संस्करणों को लॉक नहीं कर रहा है?

यदि कोई मौजूद नहीं है तो yarn install लॉकफ़ाइल बनाने का मामला है, अर्थात जब कोई किसी प्रोजेक्ट को yarn का उपयोग करने के लिए परिवर्तित कर रहा है, लेकिन इसे हमेशा लिखने का औचित्य स्पष्ट नहीं है। मैं @bestander की राय से सहमत हूं कि केवल उत्परिवर्तित क्रियाओं को add/upgrade/remove ।

क्या add/remove/upgrade पूर्व के बिना लॉकफाइल को संशोधित करने का कोई तरीका होना चाहिए: उस परिदृश्य में जब आप यार्न को अपग्रेड करते हैं और यह एक नए लॉकफाइल संस्करण का उपयोग करता है?

मुझे लगता है कि विकल्प उलटा हो सकता है

yarn install --save-lockfile

पर 17 अक्टूबर वर्ष 2016 18:53 पर, जेम्स इदे [email protected] लिखा है:

क्या लॉकफाइल को जोड़ने/निकालने/अपग्रेड किए बिना संशोधित करने का कोई तरीका होना चाहिए
उदाहरण: उस परिदृश्य में जब आप यार्न को अपग्रेड करते हैं और यह एक नए लॉकफाइल का उपयोग करता है
संस्करण?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/yarnpkg/yarn/issues/570#issuecomment -254282256, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/ACBdWJLpdvqiwcBwqE4KB3x3f4oCn_nVks5q07YYgaJpZM4KSlSw
.

मैं भी इससे भ्रमित हूं। वर्तमान डिफ़ॉल्ट व्यवहार का तर्क क्या है?

अफैक, डिफ़ॉल्ट व्यवहार के लिए कोई मजबूत कारण नहीं था।
मुझे लगता है कि विचार लोगों की लॉकफाइल को "सदाबहार" रखना है।

बीटीडब्ल्यू पीआर का स्वागत है

मुझे लगता है कि इसका कारण यह था कि यार्न मूल रूप से एक install कमांड के साथ डिजाइन किया गया था जिसे install/add/upgrade में विभाजित किया गया था

तो, यह जांचने के लिए कि क्या मैं इसे सही ढंग से समझता हूं:

yarn सभी निर्भरताओं को स्थापित करता है और लॉकफाइल को भी संशोधित करता है। सीआई सर्वर पर आपको yarn install --pure-lockfile उपयोग करना चाहिए?
इंस्टॉल के दौरान लॉकफाइल को संशोधित क्यों किया जाता है? चूंकि आप कुछ भी अपग्रेड नहीं कर रहे हैं ... यार्न को लॉकफाइल में वर्णित पैकेजों को स्थापित करना चाहिए, है ना?

स्पष्टीकरण के लिए धन्यवाद!

समस्या यह है कि यदि लॉकफाइल डिफ़ॉल्ट रूप से शुद्ध है तो लोग इसे अपडेट करना भूल जाएंगे क्योंकि यह एक अलग कमांड होगा।

@kittens क्या लॉक फ़ाइल को केवल किसी पैकेज को जोड़ने/निकालने/अपग्रेड करने पर अपडेट नहीं किया जाना चाहिए? उन्हें हमेशा लॉक फ़ाइल को अपग्रेड करना चाहिए, साथ ही प्रारंभिक इंस्टॉल भी करना चाहिए।

समस्या यह है कि यदि लॉकफाइल डिफ़ॉल्ट रूप से शुद्ध है तो लोग इसे अपडेट करना भूल जाएंगे क्योंकि यह एक अलग कमांड होगा

यह समस्या होना इस बात पर निर्भर करता है कि आप पैकेज मैनेजर का मुख्य उद्देश्य क्या मानते हैं।

मेरी राय में, एक पैकेज प्रबंधक द्वारा भरी जाने वाली भूमिकाओं में से एक परियोजना पर विकास के साथ शुरुआत करना जितना संभव हो उतना आसान बनाना है। एक साधारण yarn install को वे सभी पैकेज मिलने चाहिए जो आपको विकसित करना शुरू करने के लिए चाहिए, बिना किसी भ्रम के।

npm मेरे पास डेवलपर्स के एक प्रोजेक्ट में शामिल होने के कई उदाहरण हैं, केवल एक प्रोजेक्ट खोजने के लिए उनकी मशीन पर काम नहीं करता है। ये उदाहरण क्षणिक निर्भरता के कारण हुए हैं जो संस्करणों को तोड़ने वाले परिवर्तनों के साथ संस्करणों में टकरा रहे हैं या बस सेवर का पालन नहीं कर रहे हैं। मुझे उम्मीद थी कि yarn इन मुद्दों को हल करेगा, लेकिन अगर टेकअवे यह है कि एक परियोजना के सभी डेवलपर्स को yarn install --pure-lockfile चलाना चाहिए ताकि 100% सुनिश्चित हो सके कि परियोजना का निर्माण होने जा रहा है, तो ऐसा नहीं है मामला।

पैकेज मैनेजर की एक अन्य भूमिका परियोजनाओं को उनकी निर्भरता पर नियंत्रण देना है। यदि इसे डिफ़ॉल्ट रूप से शुद्ध किया जाता है, तो डेवलपर्स पुराने संस्करणों को देखने के लिए yarn outdated पर एक नज़र डाल सकते हैं और फिर किसी भी ब्रेकिंग परिवर्तन से बचने के लिए परिवर्तन नोटों की समीक्षा कर सकते हैं। यह डेवलपर्स को आकस्मिक लॉकफाइल कमिट से बचने के लिए डेवलपर्स को git commit -a करने से प्रतिबंधित करने के बजाय किसी दिए गए रिलीज़ समय सीमा में केवल बंप संस्करणों पर पूर्ण नियंत्रण देगा।

मैं @esphen की हर बात से सहमत हूं। मुझे आश्चर्य है कि शुद्ध व्यवहार यार्न में डिफ़ॉल्ट नहीं है - मैंने सोचा था कि इस तरह की स्थिरता एनपीएम पर यार्न का प्रमुख लाभ था। जिस तरह से मैं इसे देखता हूं, एनपीएम से स्विच करने का यह सबसे सम्मोहक कारण होना चाहिए।

कुछ दिनों के लिए yarn का उपयोग शुरू करने के बाद बिल्ड को तोड़कर हमें पूरी तरह से आश्चर्यचकित कर दिया। मैंने ईमानदारी से सोचा था कि --pure-lockfile बहुत सारे दस्तावेज़ों को पढ़ने के बाद डिफ़ॉल्ट व्यवहार था और यह कैसे सिकुड़ते हुए npm से बेहतर है। कृपया डिफ़ॉल्ट बनाएं :)

@ide एक ऐसे परिदृश्य की कल्पना करें जहां कोई व्यक्ति केवल package.json अपडेट करता हो, yarn.lock को कैसे अपडेट किया जाएगा?

क्या कोई कृपया उन परिदृश्यों को लिख सकता है जिनके कारण लॉकफाइल को अप्रत्याशित रूप से संशोधित किया जा रहा है? यह परिवर्तन एक गंभीर एक है और स्पष्ट जो याद में भूमि के ऊपर का एक बहुत क्या आपरेशनों में यह अद्यतन आदि किया जा रहा परिणाम का मतलब होने के लिए यह करने के लिए अद्यतन की आवश्यकता द्वारा lockfile एक द्वितीय श्रेणी के नागरिक पड़ता है

उपरोक्त के बारे में अधिक जानकारी: हमारे निर्माण में जीथब से एक उप-निर्भरता के रूप में कॉफ़ीस्क्रिप्ट है। कॉफ़ीस्क्रिप्ट ने कुछ कामों को आगे बढ़ाया और हमें अपनी निर्माण प्रक्रिया में केवल yarn install चलाने से संशोधित yarn.lock मिला:

diff --git a/foo/yarn.lock b/foo/yarn.lock
index ec667fa..bb1f6ae 100644
--- a/foo/yarn.lock
+++ b/foo/yarn.lock
@@ -930,9 +930,9 @@ code-point-at@^1.0.0:
   version "1.6.3"
   resolved "https://registry.yarnpkg.com/coffee-script/-/coffee-script-1.6.3.tgz#6355d32cf1b04cdff6b484e5e711782b2f0c39be"

-"coffee-script<strong i="8">@github</strong>:jashkenas/coffeescript":
+coffee-script@jashkenas/coffeescript:
   version "1.11.1"
-  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/887052de079b2f0af9f080031a00bb7544eaca08"
+  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/0d132318ce8f7116a436d97db1f2a5c8b1dedf28"

 [email protected]:
   version "0.3.0"

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

मैं yarn install को एक कमांड के रूप में देखता हूं जो मेरे लिए नोड_मॉड्यूल बनाता है।
यह yarn add और yarn remove विपरीत है जो package.json, यार्न.लॉक और क्लीनअप node_modules को संशोधित करता है।
add और remove विरोध में मैं install 100 गुना अधिक बार दौड़ता हूं, खासकर सीआई में जहां मुझे कभी भी साइड इफेक्ट होने की उम्मीद नहीं है।

उदाहरण जब मैं चीजों को बदलने की उम्मीद नहीं करता:

1. मैं यार्न 0.15.0 पर हूं, मेरी टीम के साथी यार्न 0.16.0 पर हैं।
   क्योंकि 0.16.0 ने यार्न में प्रविष्टियों के बीच रिक्त स्थान जोड़ा। हर बार जब मैं यार्न के खिलाफ yarn install चलाता हूं। मेरी टीम के साथी द्वारा उत्पन्न लॉक मुझे एक संशोधित यार्न। लॉक फ़ाइल मिलती है जिसे मुझे याद रखने की आवश्यकता नहीं है।
   और इसके विपरीत।
2. मेरे अन्य निर्माण उपकरण node_modules राज्य के "सत्य के स्रोत" के रूप में यार्न.लॉक पर निर्भर करते हैं। अगर यह अप्रत्याशित रूप से बदलता है तो मुझे अपने निर्माण में गैर नियतत्ववाद मिलेगा

@ बिल्ली के बच्चे

समस्या यह है कि यदि लॉकफाइल डिफ़ॉल्ट रूप से शुद्ध है तो लोग इसे अपडेट करना भूल जाएंगे क्योंकि यह एक अलग कमांड होगा।

ऐसे परिदृश्य की कल्पना करें जहां कोई व्यक्ति केवल npm का उपयोग कर रहा हो और package.json को अपडेट कर रहा हो, तो यार्न.लॉक को कैसे अपडेट किया जाएगा?

यदि हम मानते हैं कि yarn install को yarn.lock अपडेट नहीं करना चाहिए, तो यह भी विफल हो जाना चाहिए यदि yarn.lock इस तथ्य को उजागर करने के लिए package.json साथ सिंक से बाहर है कि एक yarn install --save-lockfile सब कुछ वापस सिंक में लाने के लिए

+1 यार्न इंस्टाल यार्न को म्यूटेट नहीं करना चाहिए।लॉक

1. डिबगर एक oss ऐप है। हम चाहते हैं कि योगदानकर्ता यार्न इंस्टाल कर सकें और _good_ संस्करण प्राप्त कर सकें। हमने लोगों को npm स्थापित किया है और कहते हैं कि यह सकर्मक गुणों के कारण टूट रहा है। यार्न इंस्टॉल के साथ, योगदानकर्ता यार्न इंस्टॉल करते हैं और यह नहीं जानते कि यार्न लॉक परिवर्तनों के साथ क्या करना है।

मैं लॉक फ़ाइल को अपडेट करने के बारे में चिंतित नहीं हूं। आदर्श रूप से ग्रीनकीपर ऐसा तब करेगा जब डीपीएस बदल जाएगा और हम लॉक फ़ाइल परिवर्तन को मर्ज कर सकते हैं।

मैं इस मुद्दे को इसके बारे में वर्तमान विचारों के साथ अद्यतन करना चाहता हूं। @kittens और मैं दोनों सोचते हैं कि कुछ कारणों से --pure-lockfile _not_ डिफ़ॉल्ट होना चाहिए।

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

एक बार जब आप मैन्युअल रूप से package.json को संशोधित कर लेते हैं तो यार्न और npm दोनों में अपेक्षा यह होती है कि जब आप दूसरा चलाते हैं तो इसे package.json साथ _syncs_ इंस्टॉल करें। उस अर्थ में yarn install का लगभग नाम बदला जा सकता है yarn sync ।

समन्वयन के विषय पर, जब आप नई निर्भरता के साथ एक संस्थापन चलाते हैं तो आप node_modules निर्देशिका से उन परिवर्तनों को प्रतिबिंबित करने की अपेक्षा करते हैं। चूंकि yarn.lock node_modules सहायक के रूप में कार्य करता है,

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

एक तरफ ध्यान दें, मेरा मानना ​​​​है कि बहुत से लोग जो इस मुद्दे के समर्थन में आवाज उठा रहे हैं, वे भ्रमित हैं कि वास्तव में यहां क्या चर्चा की जा रही है।

डिफ़ॉल्ट रूप से --pure-lockfile का उपयोग करने का मतलब यह नहीं है कि यार्न सुसंगत और विश्वसनीय परिणाम नहीं देता है। वही package.json परिणामस्वरूप वही yarn.lock होगा जिसके परिणामस्वरूप वही node_modules 100% समय होगा।

जब आप अपने package.json अपने yarn.lock फ़ाइल अपडेट और फिर अपने node_modules अपडेट को अपडेट करते हैं। यह चीजों के लिए एक बहुत ही स्वाभाविक क्रम है और हमें इसे इसी तरह रखना चाहिए

जब आपने अपना package.json अपडेट किया है, लेकिन सीआई के संबंध में अलग-अलग निर्भरताएं प्राप्त करने में सक्षम हैं, लेकिन सब कुछ सिंक करने के लिए yarn install नहीं चलाया है, जो मुझे यकीन है कि कोई लाएगा (हालांकि मुझे ऐसा नहीं दिखता है एक मुद्दा) - मैं और अन्य लोग यार्न को एकीकृत करने के बारे में विभिन्न सीआई टूल से बात कर रहे हैं, अगर लोग इसे एक बड़े मुद्दे के रूप में देखते हैं तो हम उन्हें डिफ़ॉल्ट रूप से --pure-lockfile का उपयोग करने के लिए आसानी से धक्का दे सकते हैं।

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

@thejameskyle अगर आप कुछ स्पष्ट कर सकते हैं तो मैं इसकी सराहना करता हूं:

1. एक डेवलपर के पास एक package.json होता है जिसमें एक निर्भरता "foo": "^1.0.0"
2. डेवलपर yarn install चलाता है। foo पैकेज वर्तमान में 1.0.0 संस्करण है, इसलिए यह एक yarn.lock फ़ाइल बनाता है जो [email protected] में लॉक हो जाती है
3. डेवलपर Git में yarn.lock जोड़ता है।
4. डेवलपर रेपो की अपनी स्थानीय प्रति पर यूनिट परीक्षण चलाता है, सब कुछ ठीक काम करता है।
5. डेवलपर अपने रेपो को CI (जैसे ट्रैविस) पर धकेलता है।
6. सीआई yarn install चलाता है, लेकिन foo अब संस्करण 1.1.0 अपडेट हो गया है, इसलिए यार्न [email protected] स्थापित करता है और yarn.lock को नए संस्करण के साथ अधिलेखित कर देता है foo
7. सीआई टूट जाता है क्योंकि foo में 1.1.0 . संस्करण में एक ब्रेकिंग परिवर्तन था

यहां ऐसी ही स्थिति है:

1. एक डेवलपर के पास एक package.json होता है जिसमें एक निर्भरता "foo": "^1.0.0" , जिसे [email protected] रूप में लॉक किया जाता है, और yarn.lock को Git में सहेजा जाता है।
2. रेपो के डेवलपर की स्थानीय प्रति पर यूनिट परीक्षण ठीक काम करते हैं।
3. एक योगदानकर्ता रेपो को एक संशोधन + पुल अनुरोध करने के इरादे से क्लोन करता है।
4. जब योगदानकर्ता yarn install चलाता है तो उन्हें संस्करण [email protected] जिसके कारण yarn.lock अपडेट हो जाता है।
5. अब योगदानकर्ता का निर्माण टूट गया है क्योंकि foo संस्करण 1.1.0 में एक ब्रेकिंग परिवर्तन था

मुझे लगता है कि ये ऐसी स्थितियां हैं जिनसे ज्यादातर लोग चिंतित हैं।

इसलिए यदि आप स्पष्ट कर सकते हैं कि yarn install के वर्तमान व्यवहार में उपरोक्त समस्याएं नहीं हैं, तो मुझे लगता है कि इससे हमारे अधिकांश डर दूर हो जाएंगे। :+1:

उन स्थितियों में से कोई भी लागू नहीं होता है। सिर्फ इसलिए कि एक निर्भरता अपडेट हो गई है इसका मतलब यह नहीं है कि आप इसे प्राप्त करेंगे, केवल अगर आपने अपने package.json परिवर्तन किए हैं।

मैं सिर्फ इस मुद्दे को बंद करने जा रहा हूं क्योंकि ऐसा लगता है कि लोगों की यही एकमात्र चिंता है, जैसा कि मैंने कहा कि यह वास्तविक परिदृश्य नहीं है। यह समस्या शायद और अधिक भ्रम पैदा कर रही है।

लेकिन अगर जीथब से निर्भरता स्थापित की जा रही है, तो इसका बुरा व्यवहार है, जैसा कि मैंने ऊपर बताया है

@adamchainz इसे अलग से तय किया जाना चाहिए, हम इसे आसानी से कमिट में लॉक कर सकते हैं

उन स्थितियों में से कोई भी लागू नहीं होता है। सिर्फ इसलिए कि एक निर्भरता अपडेट हो गई है इसका मतलब यह नहीं है कि आप इसे प्राप्त करेंगे, केवल अगर आपने अपने package.json परिवर्तन किए हैं।

@thejameskyle : मुझे यकीन नहीं है कि मैं समझता हूं कि यह वास्तविक परिदृश्य क्यों नहीं है। क्या आप कृपया विस्तृत कर सकते हैं?

एक ज्ञापन समारोह की कल्पना करें जहां इनपुट package.json और आउटपुट yarn.lock ।

1. पहली बार जब आप package.json यह yarn.lock बनाता है और परिणाम को कैश करता है।
2. अगली बार जब आप _वही_ package.json चलाते हैं तो परिणाम बिल्कुल वैसा ही होगा क्योंकि यह कैश्ड है।
3. जब आप package.json बदलते हैं तो आपने कैश को अमान्य कर दिया है और अब yarn.lock की पुनर्गणना की जाएगी।

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

कमिट और नए संस्करणों के मामले में पैकेज के साथ क्या होता है _ should_ _ अप्रासंगिक हो (यदि हमारे पास git कमिट के साथ बग है तो हमें इसे अलग से ठीक करना चाहिए, लेकिन यह इस मुद्दे से असंबंधित है)।

यह जितना मैंने बनाया है उससे कहीं अधिक जटिल है (प्रत्येक पैकेज संस्करण प्रभावी रूप से "यादगार" हो जाता है, एक पैकेज के संस्करण को बदलने से बाकी को अमान्य नहीं किया जाता है), लेकिन उम्मीद है कि अब सभी को बिंदु मिल जाएगा।

@thejameskyle : स्पष्टता (और जिज्ञासा) के लिए, मान लें कि मेरे पास yarn.lock फ़ाइल वाला एक प्रोजेक्ट है, और कोई व्यक्ति रिपॉजिटरी को नीचे खींचता है। yarn install या npm install चलाए बिना, यह व्यक्ति package.json फ़ाइल में एक नई निर्भरता जोड़ता है और फिर yarn install चलाता है। क्या इस मामले में मौजूदा yarn.lock फ़ाइल को पूरी तरह से नज़रअंदाज़ कर दिया जाएगा?

यहाँ विभिन्न चीजों का एक समूह चल रहा है जिसे मैं सुलझाने की कोशिश करना चाहता था (कोई इरादा नहीं)।

सबसे पहले, लोगों ने कई अलग-अलग आवश्यकताओं को उठाया है जो मुझे लगता है कि विवादास्पद हैं (और जो कुछ मौजूदा व्यवहार बग बनाते हैं, जिन्हें मैं जल्द ही प्राप्त करूंगा)।

मूल बग रिपोर्ट से।

जब लॉकफाइल को पर्यावरण (वर्तमान में स्थापित यार्न का संस्करण) के आधार पर संशोधित किया जाता है, तो संगति खो जाती है।
अपेक्षित व्यवहार क्या है?
यार्न इंस्टॉल करते समय यार्न.लॉक या पैकेज.जेसन न लिखें।
यार्न अपडेट करने के लिए। लॉक यार्न अपग्रेड का उपयोग करें

अधिक सटीक होने के लिए, अपेक्षित शब्दार्थ, मेरी राय में, हैं:

• यदि package.json पिछली बार yarn.lock बदले जाने के बाद से नहीं बदला है, तो yarn.lock सत्य का स्रोत है और इसे अद्यतन नहीं किया जाना चाहिए।
• यदि package.json , पिछली बार के बाद से बदल गया है yarn.lock बदल गया है, अद्यतन yarn.lock यह इतना संतुष्ट package.json और अद्यतन node_modules ।
• यदि yarn update चलाया जाता है, तो सभी निर्भरताओं को फिर से हल करें और package.json संतुष्ट करने वाली हर चीज का नवीनतम संस्करण प्राप्त करें।

इसका मतलब यह है कि जब किसी मशीन पर रिपॉजिटरी को पहली बार क्लोन किया जाता है , यदि yarn.lock को चेक इन किया गया था, तो यार्न को इसे हमेशा सत्य के स्रोत के रूप में मानना ​​चाहिए, न कि yarn.lock अपडेट उत्पन्न करना, और कूदना सीधे लाने के लिए कदम।

इस हद तक कि यह यार्न का वर्तमान व्यवहार नहीं है, मेरा मानना ​​​​है कि यह एक बग होगा।

@esphen ने लिखा:

मैं सहमत हूं। इस बात पर चर्चा होनी चाहिए कि क्यों यार्न इंस्टाल डिफ़ॉल्ट रूप से लॉकफाइल लिखता है, क्योंकि यह संपूर्ण लॉकफाइल अवधारणा के साथ बाधाओं पर लगता है। लॉकफाइल क्यों है यदि यह डिफ़ॉल्ट रूप से संस्करणों को लॉक नहीं कर रहा है?

मुझे लगता है कि यह कहने की कोशिश कर रहा है कि अगर मौजूदा अभी भी अद्यतित है तो यार्न को एक नया लॉकफाइल नहीं लिखना चाहिए। मैं इससे सहमत हूँ।

मैं @bestander की राय से सहमत हूं कि केवल उत्परिवर्तित क्रियाओं को डिफ़ॉल्ट रूप से

यहां मुख्य समस्या यह है कि क्या package.json बदलाव के कारण yarn.lock अपडेट हो जाना चाहिए। मेरी राय में, यदि करने के लिए परिवर्तन package.json से संतुष्ट नहीं है yarn.lock , यह अद्यतन करना होगा yarn.lock ।

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

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

@ गुज़ ने कहा:

तो, यह जांचने के लिए कि क्या मैं इसे सही ढंग से समझता हूं:
यार्न सभी निर्भरताओं को स्थापित करता है और लॉकफाइल को भी संशोधित करता है। सीआई सर्वर पर आपको यार्न इंस्टाल -- प्योर-लॉकफाइल का उपयोग करना चाहिए?

यह प्रश्न उस भावना को प्रतिध्वनित करता है जिसे कुछ लोगों ने इस सूत्र में बनाया है।

कार्गो में --locked ध्वज है जो कहता है "यदि package.json yarn.lock संतुष्ट नहीं है, तो यह एक कठिन त्रुटि है"। बंडलर के पास एक समान ध्वज ( --frozen ) है, जिसे तब जोड़ा गया था जब हेरोकू ने बंडलर को अपनाया था, ताकि लोगों को उनके Gemfile स्थानीय परिवर्तन करने और Gemfile.lock में जांचना भूल जाने पर एक कठिन त्रुटि दी जा सके।

विचार यह है कि आपके सामान्य विकास के दौरान, आप package.json परिवर्तन करने में सक्षम होना चाहते हैं और यार्न सुनिश्चित करना चाहते हैं कि yarn.lock सिंक में रहता है (फिर से, यह सुनिश्चित करने के लिए कि निर्दिष्ट संस्करण package.json हमेशा अभ्यास में उपयोग की जाने वाली चीज़ों से मेल खाता है)।

लेकिन तैनाती करते समय, यह लगभग हमेशा एक त्रुटि होती है, क्योंकि इसका मतलब है कि आपने package.json बदलाव किया है, एक स्थानीय yarn कमांड चलाया, और yarn.lock में जांचना भूल गए . इसका मतलब यह है कि आपके package.json संस्करण एप्लिकेशन चलाने के दौरान उपयोग किए गए वास्तविक संस्करणों से मेल नहीं खाते हैं , जो हमने कहा है कि यार्न के एक मौलिक अपरिवर्तनीय का उल्लंघन करता है।

@esphen ने कहा:

मेरी राय में, एक पैकेज प्रबंधक द्वारा भरी जाने वाली भूमिकाओं में से एक परियोजना पर विकास के साथ शुरुआत करना जितना संभव हो उतना आसान बनाना है। एक साधारण यार्न इंस्टाल को वे सभी पैकेज मिलने चाहिए जिन्हें आपको विकसित करना शुरू करने की आवश्यकता है, बिना किसी भ्रम के।

मुझे लगता है कि यह गैर-विवादास्पद है।

एनपीएम के साथ मेरे पास डेवलपर्स के एक प्रोजेक्ट में शामिल होने के कई उदाहरण हैं, केवल एक प्रोजेक्ट खोजने के लिए उनकी मशीन पर काम नहीं करता है। ये उदाहरण क्षणिक निर्भरता के कारण हुए हैं जो संस्करणों को तोड़ने वाले परिवर्तनों के साथ संस्करणों में टकरा रहे हैं या बस सेवर का पालन नहीं कर रहे हैं। मुझे उम्मीद थी कि यार्न इन मुद्दों को हल करेगा, लेकिन अगर टेकअवे यह है कि किसी प्रोजेक्ट के सभी डेवलपर्स को यार्न इंस्टॉल - प्योर-लॉकफाइल चलाना चाहिए, तो 100% सुनिश्चित हो कि प्रोजेक्ट बनने जा रहा है, तो ऐसा नहीं है।

yarn install --pure-lockfile चलाने का मतलब यह होगा कि लॉकफाइल का सम्मान किया जाएगा, भले ही लॉकफाइल के अंदर के संस्करण package.json में निर्दिष्ट संस्करणों के साथ संघर्ष करें। यह केवल पहली जगह में उठता है, तो एक डेवलपर भूल उनके चेक इन करने चाहिए yarn.lock करने के लिए परिवर्तन करने के बाद package.json ।

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

यदि package.json नहीं बदला है, तो मेरी राय में यह एक बग है यदि yarn.lock अपडेट हो रहा है। मूल रिपोर्ट में बग का कम से कम एक मामला प्रतीत होता है:

लॉकफाइल को पर्यावरण (वर्तमान में स्थापित यार्न का संस्करण) के आधार पर संशोधित किया गया है।

मुझे लगता है कि यह एक गलती है और इसे ठीक किया जाना चाहिए।

बाद में सूत्र में, @thejameskyle ने कहा:

एक मेमोइज़ फ़ंक्शन की कल्पना करें जहां इनपुट एक package.json है और आउटपुट यार्न.लॉक है।

यह बिल्कुल सही मानसिक मॉडल है, मेरे विचार में (" yarn.lock बदल सकता है अगर और केवल अगर package.json बदल गया"), और अगर अमूर्त लीक हो जाता है तो हमें इसे ठीक करना चाहिए।

@adamchainz ने कहा:

उपरोक्त के बारे में अधिक जानकारी: हमारे निर्माण में जीथब से एक उप-निर्भरता के रूप में कॉफ़ीस्क्रिप्ट है। कॉफ़ीस्क्रिप्ट ने कुछ कमिट्स को आगे बढ़ाया और हमें एक संशोधित यार्न मिला। हमारी निर्माण प्रक्रिया में सिर्फ यार्न इंस्टाल चलाने से लॉक करें

और बादमें:

लेकिन अगर जीथब से निर्भरता स्थापित की जा रही है, तो इसका बुरा व्यवहार है, जैसा कि मैंने ऊपर बताया है

यहाँ समस्या यह है कि यार्न git sha को git निर्भरता के लॉक किए गए संस्करण के हिस्से के रूप में नहीं मानता है। कार्गो और बंडलर दोनों में "सटीक" संस्करण की अवधारणा है जिसे लॉकफाइल में क्रमबद्ध किया गया है; गिट स्रोतों के लिए, "सटीक" संस्करण SHA है। तब, जब आप के साथ एक ताजा क्लोन बनाने के लिए सिर्फ एक package.json और yarn.lock और चलाने yarn , ठीक कोड की जरूरत है पाने के लिए आवश्यक जानकारी के सभी है।

मुझे यह स्वीकार करना होगा कि मूल गिट कोड की समीक्षा करते समय मैंने इस बातचीत को याद किया; कोड में कुछ SHA ट्रैकिंग है, लेकिन yarn install यह सुनिश्चित नहीं करता है कि हाइड्रेटेड निर्भरता ग्राफ इसका सम्मान करता है।

टीएल; डीआर

मैं @thejameskyle और @kittens साथ सहमत हैं कि yarn.lock के साथ सिंक में रखा जाना चाहिए package.json स्वचालित रूप से, क्योंकि मुझे विश्वास है कि उन है कि संस्करण उनके में निर्दिष्ट ग्रहण करने के लिए सक्षम होना चाहिए package.json उनके ऐप को निष्पादित करते समय उपयोग किए जाने वाले कार्यों के साथ लाइन अप करें।

हालांकि, कुछ बग प्रतीत होते हैं जो yarn.lock में अनुचित मंथन का कारण बन रहे हैं, भले ही package.json नहीं बदला है:

• मशीनों में यार्न संस्करण में परिवर्तन लॉकफाइल को अपडेट करता है
• package.json अपडेट नहीं होने पर भी git निर्भरताएँ अपडेट हो जाती हैं, जो तब लॉकफाइल को अपडेट करता है

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

@thejameskyle धन्यवाद! :heart: मैं आपसे और @kittens से सहमत हूं कि yarn.lock को package.json बदलने के बाद अपडेट किया जाना चाहिए

@wycats हमेशा की तरह एक बहुत ही गहन और व्यावहारिक पोस्ट। :+1: मैं आपसे सहमत हूं, और मुझे --locked ध्वज (या समान) का विचार भी पसंद है। हमें इसके बारे में एक नया मुद्दा बनाना चाहिए।

git SHA समस्या को ट्रैक करने के लिए #1568 बनाया गया

@wycats ,

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

ठीक यही कारण है कि इस मुद्दे को खोला गया है।
हमारे पास कंपनी में यार्न के कुछ सक्रिय संस्करण हैं और हमारे पैमाने पर मुझे नहीं लगता कि हम हर जगह परमाणु अपडेट कर पाएंगे।
यार्न पर बनाता है 0.13, 0.14 और 0.15 ने यार्न.लॉक फाइलों में मामूली बदलाव पेश किए, भले ही package.json सिंक में था।
इसने कुछ मुद्दों का कारण बना, उदाहरण के लिए बक बिल्ड धीमा कर दिया गया क्योंकि स्रोत पेड़ में परिवर्तन कैश को अमान्य कर देता है।
इसने मुझे और कुछ टीमों को कुछ घंटों के काम का कारण बना दिया।

@thejameskyle , अपनी राय साझा करने के लिए धन्यवाद।
मैंने package.json के यार्न.लॉक के साथ सिंक से बाहर होने के परिदृश्य को उचित नहीं माना। और आपके पास एक वैध बिंदु है।

हालाँकि जैसा कि @wycats ने बताया, मूल बग रिपोर्ट मान्य है।
वैध बिल्ड के लिए इसे ठीक करना महत्वपूर्ण है और मैं एक समाधान के साथ आने के इरादे से इस मुद्दे को फिर से खोलूंगा जो सभी इच्छुक पार्टियों को संतुष्ट करता है।

@wycats

अधिक सटीक होने के लिए, अपेक्षित शब्दार्थ, मेरी राय में, हैं:

• यदि package.json पिछली बार yarn.lock बदले जाने के बाद से नहीं बदला है, तो yarn.lock सत्य का स्रोत है और इसे अद्यतन नहीं किया जाना चाहिए।
• यदि package.json , पिछली बार के बाद से बदल गया है yarn.lock बदल गया है, अद्यतन yarn.lock यह इतना संतुष्ट package.json और अद्यतन node_modules ।
• यदि yarn update चलाया जाता है, तो सभी निर्भरताओं को फिर से हल करें और package.json संतुष्ट करने वाली हर चीज का नवीनतम संस्करण प्राप्त करें।

इसका मतलब यह है कि जब किसी मशीन पर रिपॉजिटरी को पहली बार क्लोन किया जाता है , यदि yarn.lock को चेक इन किया गया था, तो यार्न को इसे हमेशा सत्य के स्रोत के रूप में मानना ​​चाहिए, न कि yarn.lock अपडेट उत्पन्न करना, और कूदना सीधे लाने के लिए कदम।

ये वे शब्दार्थ हैं जिनका हम अनुसरण करते हैं जिन्हें मैंने #364 में जोड़ा है।

@bestander आप पीआर (#364) में शामिल थे जिसने इन हेरिस्टिक्स को जगह में रखा। आप कौन से अतिरिक्त परिवर्तन प्रस्तावित कर रहे हैं?

यह मुद्दा बहुत व्यापक है और हम पहले ही सहमत हो चुके हैं कि --pure-lockfile डिफ़ॉल्ट नहीं होगा और हम @wycats द्वारा उल्लिखित अनुमानों का पालन करेंगे। यदि इस मुद्दे को खुला रखना है तो शीर्षक को इस व्यवहार के साथ वर्तमान मुद्दे को प्रतिबिंबित करने की आवश्यकता है।

@kittens अच्छा लगता है, मैं इस मुद्दे को अपडेट कर दूंगा।
या हो सकता है कि जब package.json नहीं बदला, तो मुझे लॉकफाइल को बदलने से संबंधित एक नया खोलना चाहिए

क्या हम एक नए मुद्दे पर जा सकते हैं? यहां यह टिप्पणियां केवल एक संग्रह के रूप में संरक्षित की जा सकती हैं

अच्छा लगता है, @thejameskyle , मैं आज एक नया मुद्दा

नया केंद्रित मुद्दा बनाया https://github.com/yarnpkg/yarn/issues/1576

yarn install विफल होने का विकल्प होना दिलचस्प होगा यदि package.json में पैकेज यार्न में नहीं है। लॉक, यानी। विफल अगर कोई पैकेज लॉक नहीं है

स्पष्टीकरण जोड़ना जो उपरोक्त पढ़ने के बाद भी मेरे लिए अस्पष्ट था:

टीडीआर; package.json में असंबंधित परिवर्तन पैकेज को उसके अपरिवर्तित package.json सेमर के साथ संगत नवीनतम संस्करण में अपडेट नहीं करेंगे।

ऊपर दिए गए कुछ शब्दों के आधार पर, ऐसा लग रहा था कि yarn.lock को package.json हैश पर कुंजीबद्ध किया गया था, और इस प्रकार ऐसा लग रहा था कि yarn.lock को लिखा जाएगा (अद्यतन / कैश अमान्य ) किसी भी परिवर्तन पर package.json , जो एक असंबंधित परिवर्तन (यानी, "description" या किसी अन्य निर्भरता के लिए अद्यतन) के बाद से समस्याग्रस्त होगा, उस निर्भरता के yarn.lock संस्करण को अद्यतन करने का कारण हो सकता है उसी मौजूदा package.json सेवर के भीतर एक नया संस्करण।

हालांकि, मैंने सत्यापित किया है कि पैकेज की yarn.lock प्रविष्टि केवल तभी लिखी जाती है जब यह संबंधित package.json सेवर को अपडेट किया जाता है (भले ही नया सेवर मौजूदा yarn.lock संस्करण के साथ संगत हो, और परिणामस्वरूप अन्यथा संस्करण अद्यतन की आवश्यकता नहीं होगी)।

उदाहरण के लिए,

• कहें yarn add lodash@^4.17.1 इंस्टॉल [email protected]
• बाद में, [email protected] उपलब्ध है।
• यार्न [email protected] स्थापित करना जारी रखेगा
• जब तक/जब तक लॉश का संस्करण package.json में बदल नहीं जाता (या यार्न ऐड/अपग्रेड/निकालें विशेष रूप से लॉश के विरुद्ध चलाया जाता है)।

ब्रेडक्रंब #1576

बीटीडब्ल्यू अगर आप इस तरह के छोटे लेखों के साथ दस्तावेज़ों में योगदान देने के इच्छुक हैं जो समुदाय के लिए बहुत अच्छा होगा।
कोर टीम सभी मुद्दों को ठीक करने और नई सुविधाओं को जोड़ने में व्यस्त है और यदि समुदाय दस्तावेज़ीकरण को बनाए रखने में मदद करता है तो इसकी अपेक्षा और सराहना की जाती है

@CrabDude आपकी स्पष्टीकरण साझा करने के लिए धन्यवाद।

क्या आपका मतलब है - आपके उपरोक्त उदाहरण में - कि केवल lodash और इसकी अपनी निर्भरताओं के लॉक संस्करण yarn.lock में अपडेट होंगे? उदाहरण के लिए यदि किसी अन्य निर्भरता का नया लॉक संस्करण हो सकता है तो यह उसी समय अपडेट नहीं होगा?

या दूसरा उदाहरण: मान लें कि yarn.lock गंभीर रूप से पुराना है, और उपयोगकर्ता package.json में एक नई निर्भरता जोड़ने के लिए yarn add चलाता है। क्या अन्य सभी पुराने पैकेज अब yarn.lock में अपडेट किए जाएंगे, या वे वही रहेंगे?

@रार्किन्स

क्या आपका मतलब है - आपके उपरोक्त उदाहरण में - कि केवल लॉश और इसकी अपनी निर्भरताओं के लॉक संस्करण यार्न.लॉक में अपडेट होंगे?

हां। ऐसा लगता है कि मेरे उदाहरण में इसे बरकरार रखा गया है।

क्या अन्य सभी पुराने पैकेज अब यार्न.लॉक में अपडेट किए जाएंगे, या वे वही रहेंगे?

ऐसा लगता है कि गैर- lodash निर्भरता पेड़/पैकेज की लॉक प्रविष्टियां अपडेट नहीं की जाएंगी; केवल lodash की उप-निर्भरताएं होंगी।

मेरे दृष्टिकोण से, इनमें से प्रत्येक वांछनीय और अपेक्षित दोनों है।

प्रस्तावना : मुझे सूत पसंद है। लेकिन यह मुझे अंत तक निराश करता है।

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

यार्न से मेरी अपेक्षा यह थी कि यह सभी मशीनों में _by default_ समान नोड_मॉड्यूल सुनिश्चित करेगा। अतिरिक्त झंडे के साथ नहीं। यह सुविधा पर शुद्धता को प्राथमिकता देगा। अगर मुझे अनिश्चितता चाहिए तो मैं सीधे npm का उपयोग कर सकता हूं। जब कोई फ़ाइल बदलती है, तो यह मेरे लिए एक संकेत है कि कुछ ने इसे बदल दिया है और मुझे इसकी जांच करनी चाहिए। यह नहीं बदलना चाहिए।

प्रशन

• क्या यह कहा जा रहा है कि लॉकफाइल बदलने के बावजूद, नोड_मॉड्यूल्स की सामग्री हमेशा समान होगी जब इसे उत्पन्न किया गया था? मुझे विश्वास नहीं है कि यह मामला है लेकिन अगर ऐसा है, तो मैं इस धागे में भ्रम को समझता हूं - इसका मतलब यह होगा कि यार्न दिखने के बावजूद सही काम करता है।
• जब package.json बदलता है, तो लॉकफ़ाइल पुन: उत्पन्न हो जाती है। क्या उस विशेष प्रोग्रामर के नोड_मॉड्यूल्स की स्थिति के आधार पर अनजाने में बहुत सारी निर्भरताएँ नहीं बदल सकतीं? यार्न को एक डेल्टा निर्धारित करना चाहिए और मौजूदा तालों को यथासंभव सर्वोत्तम रूप से संरक्षित करने का प्रयास करना चाहिए (यदि यह पहले से नहीं है)।
• क्यों करता है yarn add में संस्करणों निर्दिष्ट package.json एक साथ ^ ? फिर से, मैं समझ गया कि यार्न का वादा निर्भरता को स्थिर करना था।

संबंधित कीड़े

• जब node_modules में एक यादृच्छिक पैकेज हटा दिया जाता है, तो yarn install इसे पुनः स्थापित किए बिना सफलता कहता है। जब उनमें से बहुत से चले जाते हैं, तो यह उन्हें पुनः स्थापित करता है। npm इस संबंध में थोड़ा अधिक गहन है।
• यदि आप नोड_मॉड्यूल्स को हटाते हैं और एक क्लीन इंस्टाल करते हैं तो लॉकफाइल पुन: उत्पन्न हो जाता है (जो कि वास्तव में आपकी अपेक्षा के विपरीत है - मुझे उम्मीद है कि यह लॉकफाइल में ठीक वही स्थापित करेगा और बिल्कुल कुछ नहीं करेगा)
• यदि आप पैकेज को छुए बिना लॉकफाइल को हटाते हैं या क्लीन इंस्टाल के बाद node_modules , तो यार्न इसे पुन: उत्पन्न करता है और यह आमतौर पर पिछले संस्करण की तुलना में बहुत अलग होता है। यह एक कंपाइलर की तरह है जो हर बार जब आप इसे चलाते हैं तो कुछ भी नहीं बदलने के बावजूद अलग कोड तैयार करते हैं।

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

लगातार बदलती लॉकफाइल आत्मविश्वास पैदा नहीं करती है और लगातार परेशानी होती है। मैं चेतावनियों और त्रुटियों को प्राथमिकता दूंगा कि package.json लॉकफाइल से मेल नहीं खाता है, कि लॉकफाइल नोड_मॉड्यूल्स से मेल नहीं खाता है, कि एक लॉक किया गया संस्करण अब मौजूद नहीं है, आदि, इसलिए यह मेरे बिल्ड को उनके ट्रैक में मृत कर देता है और मैं कर सकता हूं मेरी निर्भरता के बारे में जानबूझकर निर्णय लें।

@jspiro , इसे लिखने के लिए धन्यवाद।
यहां कुछ मुद्दे उठाए गए हैं।
प्रत्येक अंक को अलग से खोलना बेहतर होगा अन्यथा वे टिप्पणियों में खो जाएंगे।

क्या आप यार्न के नवीनतम संस्करण पर हैं?
0.18-0.19 तक हम मशीनों के बीच यार्न.लॉक फाइलों में संशोधन नहीं देखते हैं।

प्रशन:

क्या यह कहा जा रहा है कि लॉकफाइल बदलने के बावजूद, नोड_मॉड्यूल्स की सामग्री हमेशा समान होगी जब इसे उत्पन्न किया गया था? मुझे विश्वास नहीं है कि यह मामला है लेकिन अगर ऐसा है, तो मैं इस धागे में भ्रम को समझता हूं - इसका मतलब यह होगा कि यार्न दिखने के बावजूद सही काम करता है।

देव और वैकल्पिक निर्भरता को एक ही लॉकफाइल के लिए छोड़ा जा सकता है।
लेकिन जो बिंग स्थापित हैं, प्लेटफॉर्म विशिष्ट पैकेजों को छोड़कर, नोड_मॉड्यूल्स में समान स्थानों पर समान पैकेज होने चाहिए।

जब package.json बदलता है, तो लॉकफाइल पुन: उत्पन्न होता है। क्या उस विशेष प्रोग्रामर के नोड_मॉड्यूल्स की स्थिति के आधार पर अनजाने में बहुत सारी निर्भरताएँ नहीं बदल सकतीं? यार्न को एक डेल्टा निर्धारित करना चाहिए और मौजूदा तालों को यथासंभव सर्वोत्तम रूप से संरक्षित करने का प्रयास करना चाहिए (यदि यह पहले से नहीं है)।

यह एक अच्छा फीचर अनुरोध है, इसके लिए एक पीआर देखना अच्छा लगेगा।

यार्न पैकेज.जेसन में ^ के साथ निर्दिष्ट संस्करण क्यों जोड़ता है? फिर से, मैं समझ गया कि यार्न का वादा निर्भरता को स्थिर करना था।

यह npm के व्यवहार को दर्शाता है।
आप सटीक संस्करण के लिए yarn add [email protected] या yarn add is-array --exact ।
हो सकता है कि किसी बिंदु पर हमें सटीक संस्करण डिफ़ॉल्ट बनाना चाहिए, यह आरएफसी में एक चर्चा हो सकती है।

जब नोड_मॉड्यूल्स में एक यादृच्छिक पैकेज हटा दिया जाता है, तो यार्न इंस्टॉल इसे बिना पुनर्स्थापित किए सफलता कहता है। जब उनमें से बहुत से चले जाते हैं, तो यह उन्हें पुनः स्थापित करता है। इस संबंध में npm थोड़ा अधिक गहन है।

यार्न डिफ़ॉल्ट रूप से एक त्वरित उथला चेक चलाता है।
गहरी जांच करना धीमा होगा लेकिन हम इस पर काम कर रहे हैं, मुझे इस बात का अंदाजा है कि हम कैसे एक त्वरित गहरी जांच कर सकते हैं।
आपको नोड_मॉड्यूल में फ़ाइलों को स्पर्श नहीं करना चाहिए, हालांकि, संशोधन के लिए प्रत्येक फ़ाइल को सत्यापित करने के परिणामस्वरूप बहुत धीमी गति से स्थापित अनुभव होगा।
यदि आप उथली जाँच को छोड़ना चाहते हैं तो स्थापना से पहले node_modules/.yarn-integrity फ़ाइल को हटा दें। यह आधिकारिक नहीं है और परिवर्तन के अधीन है।
yarn install --force चलाने का एक आधिकारिक तरीका है, यह पूर्ण इंस्टॉल को मजबूर करेगा लेकिन यह एक साइड इफेक्ट के रूप में यार्न.लॉक को फिर से लिख देगा।

यदि आप नोड_मॉड्यूल्स को हटाते हैं और एक क्लीन इंस्टाल करते हैं तो लॉकफाइल पुन: उत्पन्न हो जाता है (जो कि वास्तव में आपकी अपेक्षा के विपरीत है - मुझे उम्मीद है कि यह लॉकफाइल में ठीक वही स्थापित करेगा और बिल्कुल कुछ नहीं करेगा)

कुछ समय से यह नहीं देखा।
एक मुद्दा खोलें और अगर इसे पुन: प्रस्तुत किया जा सकता है तो मुझे सीसी करें।

यदि आप क्लीन इंस्टाल के बाद पैकेज या नोड_मॉड्यूल्स को छुए बिना लॉकफाइल को हटाते हैं, तो यार्न इसे पुन: उत्पन्न करता है और यह आमतौर पर पिछले संस्करण की तुलना में बहुत अलग होता है। यह एक कंपाइलर की तरह है जो हर बार जब आप इसे चलाते हैं तो कुछ भी नहीं बदलने के बावजूद अलग कोड तैयार करते हैं।

कुछ समय बाद संक्रमणीय निर्भरता के नए संस्करण जारी किए गए होंगे।
उसके कारण उत्थापन तर्क के कारण नोड_मॉड्यूल्स की संरचना महत्वपूर्ण रूप से बदल सकती है।
यह डिजाइन के अनुसार काम करता है।
import कमांड आ रहा है https://github.com/yarnpkg/yarn/pull/2580।
यह आपको मौजूदा नोड_मॉड्यूल से लॉकफाइल बनाने की अनुमति देगा।

@jspiro , यार्न एक युवा समुदाय संचालित परियोजना है, इसे बेहतर बनाने के लिए आपके

वांछित डिफ़ॉल्ट व्यवहार सेट करने के लिए कम से कम एक विकल्प प्राप्त करने का कोई मौका?

वर्तमान में हम इस समस्या को ठीक कर रहे हैं https://github.com/yarnpkg/yarn/issues/3490 , कभी-कभी yarn install लॉकफाइल को अनुकूलित करने का कारण बन सकता है जो अपेक्षित व्यवहार नहीं है और हम इसे ठीक कर देंगे।
यही कारण हो सकता है कि आप इस परिवर्तन के लिए पूछ रहे हैं, अन्यथा यार्न.लॉक फ़ाइल केवल तभी बदलनी चाहिए जब आप मैन्युअल रूप से package.json में परिवर्तन करते हैं।

आप .yarnrc में --pure-lockfile/--frozen-lockfile को true पर सेट कर सकते हैं और इसे डिफ़ॉल्ट रूप से install कमांड में जोड़ा जाएगा:

--install.pure-lockfile true

मेरी समस्या यह है कि अगर मैं शुद्ध-लॉकफाइल का उपयोग नहीं करता हूं तो मुझे निर्भरताओं का गलत संस्करण स्थापित होता है। यह अवांछित यार्न से संबंधित नहीं है। परिवर्तन लॉक करें

क्या आप रेप्रो चरणों के साथ कोई समस्या प्रस्तुत कर सकते हैं?
हम इसे सुलझा लेंगे

मैं अच्छी तरह से जब एक के रूप में इस ने काट लिया था package.json और yarn.lock वजह से एक डेवलपर गलती के माध्यम से एक निर्भरता को जोड़ने के लिए बाहर सिंक के मिल गया npm install --save के बजाय yarn add ।

मैं सहमत नहीं कि हालांकि pure-lockfile डिफ़ॉल्ट हो सकता है और तर्क है कि बजाय चाहिए frozen-lockfile डिफ़ॉल्ट होना चाहिए yarn install ।

चूंकि frozen-lockfile एक त्रुटि संदेश देता है यदि yarn.lock और package.json सिंक से बाहर हैं। frozen-lockfile एक बिल्ड मशीन (यानी जेनकिंस) पर बहुत मददगार है क्योंकि यह उन बिल्ड को चिह्नित करेगा, जैसा कि अपेक्षित होना चाहिए, एक विफलता के रूप में।

फिर यह डेवलपर पर निर्भर करता है कि वह package.json / यार्न.लॉक में कौन सा संस्करण जोड़ना है।

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

सार हालांकि होना चाहिए:

की तरह केवल आदेश add , remove , और upgrade उत्परिवर्तित चाहिए yarn.lock ।

install को बस इतना ही करना चाहिए, अर्थात् या तो निर्भरता को उनके लॉक किए गए संस्करण में स्थापित करें या विफल हो जाएं यदि यह package.json और yarn.lock बीच एक बेमेल का पता लगाता है। (एकमात्र अपवाद यह है कि यदि पहली जगह में कोई yarn.lock है। तब, और केवल तभी, यह एक बना सकता है, फिर भी इसे कभी भी इसे फिर से छूना नहीं चाहिए।)

फ्रोजन-लॉकफाइल इसलिए बिल्ड मशीन (यानी जेनकिंस) पर बहुत मददगार है क्योंकि वे बिल्ड विफल हो जाएंगे।

मुझे लगता है कि जब हमें पता चलता है कि हम सीआई मोड में हैं तो हम इसे स्वचालित रूप से सक्षम कर सकते हैं?

@BYK मुझे नहीं पता था कि इस मुद्दे को यहां जोड़ने से पहले बंद कर दिया गया था। क्या मुझे शायद एक नया खोलना चाहिए या इसे फिर से खोला जा सकता है?

मैं कहूंगा कि एक नया खोलो ️

मैं @thejameskyle से सहमत और @kittens कि yarn.lock स्वचालित रूप से package.json के साथ सिंक में रखा जाना चाहिए

सुनिश्चित नहीं है कि यह कहा गया है, लेकिन सिर्फ मामले में: पैकेज में कुछ भी बदलने पर आपको पूरे यार्न को अमान्य करने की आवश्यकता नहीं है। जेसन। आप केवल उन्हीं पैकेजों की निर्भरता को अमान्य कर सकते हैं जिन्हें package.json के अंदर संशोधित किया गया था। Fe यदि आपने केवल टाइपस्क्रिप्ट को अपडेट किया है, तो टाइपस्क्रिप्ट की निर्भरता को संशोधित करने की आवश्यकता होगी (अन्य अपरिवर्तित पैकेजों के संबंध में विचार के साथ)।