मुझे नहीं लगता कि यह एक बग है। मैं इस मुद्दे को पुन: पेश करने में सक्षम था लेकिन अंतर था

52,55d51
< ansi-regex@*:
<   version "3.0.0"
<   resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-3.0.0.tgz#ed0317c322064f79466c02966bddb605ab37d998"
<
1352c1348
< imurmurhash@*, imurmurhash@^0.1.4:
---
> imurmurhash@^0.1.4:

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

मुझे यह स्वीकार करना होगा कि यह थोड़ा अनपेक्षित है और हम इसके लिए एक अच्छा समाधान लाने की कोशिश कर रहे हैं। आप # 4147 पर चर्चा का अनुसरण या योगदान कर सकते हैं।

यदि आप सहमत हैं कि यह बग नहीं है और # 4147 चर्चा जारी रखने के लिए एक अच्छी जगह है, तो इस मुद्दे को बंद करें :)

@BYK आपकी विचारशील प्रतिक्रिया के लिए धन्यवाद। # 4147 पढ़ने के बाद, मैं इस मुद्दे को बंद करने के बारे में बाड़ पर हूं। मुझे उम्मीद है कि यहाँ थोड़ी और चर्चा मदद कर सकती है।

4147 विशेष रूप से उस मामले के बारे में प्रतीत होता है जहां यार्न .लॉक और पैकेज.जसन सिंक में नहीं हैं - वास्तव में केवल समय अनुकूलन का उल्लेख इस टिप्पणी में है: https://github.com/yarnpkg/yarn/issues/4147 #issuecomment -321894341 - और यह टिप्पणी उस मुद्दे को छूती है जो मुझे चिंतित करता है: यार्न yarn.lock फ़ाइल को संशोधित करता है जब package.json कोई परिवर्तन नहीं किया गया है।

यह मुझे लगता है कि yarn.lock फ़ाइल को केवल तभी बदलना चाहिए जब मेरी निर्भरता किसी तरह बदल रही हो। वास्तव में, इस बिंदु तक, मैं अपने devs है कि अगर वे में परिवर्तन देख कह दिया गया है yarn.lock फ़ाइल, यह समय को चलाने के लिए yarn install । हाल ही के उन्नयन के साथ कई लोगों ने बताया कि मेरे परिवर्तन प्राप्त करने के बाद और उन्होंने yarn install भाग लिया, उनकी लॉक फ़ाइल बदल गई (अनुकूलन)। यह एक भ्रामक स्थिति के लिए बनाता है - क्या उन्हें बदलाव करना चाहिए? क्या मुझे किसी तरह लॉक फाइल को प्री-ऑप्टिमाइज करना चाहिए (क्या यह भी संभव है)?

ऐसा लगता है कि मुझे अपने अल्पावधि में --frozen-lockfile true से .yarnrc मिलाना पड़ सकता है - लेकिन मैं इस समाधान का बहुत बड़ा प्रशंसक नहीं हूं क्योंकि इसमें वर्णित वर्कफ़्लो को शामिल नहीं किया गया है # 4147 जहाँ आप package.json संपादन करते हैं और फिर yarn install चलाते हैं।

क्या यह मंशा है कि यार्न के किसी भी आह्वान को yarn.lock संशोधित किया जा सकता है?

@BYK मैं आपको इस बारे में परेशान करने के लिए माफी चाहता हूं क्योंकि मुझे पता है कि आप बहुत व्यस्त हैं - लेकिन मुझे इस पर एक निश्चित जवाब मिलने की उम्मीद है। मेरी टीम में निर्भरता परिवर्तन वितरित करने के लिए मेरा वर्कफ़्लो इसमें विकसित हुआ है:

yarn add [blah]
rm -r node_modules yarn.lock
yarn install
rm -r node_modules
yarn install

यह लॉक फ़ाइल को ठीक से अद्यतन करने के लिए लगता है (# 4476 देखें), और फिर लॉक फ़ाइल को अनुकूलित करें ताकि मेरी टीम के साथी लॉक फ़ाइल परिवर्तनों की जाँच नहीं कर रहे हैं।

क्या मेरी टीम यार्न का गलत तरीके से उपयोग कर रही है? क्या हमें हर install कमांड के साथ लॉक फाइल बदलने की उम्मीद करनी चाहिए?

@artlogic IMHO, आपकी टीम के साथियों को yarn install काउंटर-सहज ज्ञान युक्त हैं, फिर भी अभी भी कुछ ऐसा है जो आपकी टीम का प्रत्येक डेवलपर सुरक्षित रूप से कर सकता है। मुझे समझ नहीं आता कि आप उस पर प्रतिबंध क्यों लगाना चाहते हैं।

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

यदि आप अभी भी लागू करना चाहते हैं कि इंस्टॉल लॉकफाइल को नहीं छूता है, तो आपको frozen-lockfile फ्लैग का उपयोग करना चाहिए:

 yarn add {blah}

लॉकफ़ाइल में जांच करें, और फिर एक और देव उपयोग करेगा:

   yarn install --frozen-lockfile

यह --frozen-lockfile से true .yarnrc रूप में यह आपको कभी भी अपडेट करने से रोकता है, देखें: # 4570

यदि आप अपनी निर्भरता को उन्नत करना चाहते हैं, तो दौड़ें:

 yarn upgrade

यदि आप केवल एक निर्भरता को अपग्रेड करना चाहते हैं:

  yarn upgrade {blah}

आप केवल एक निर्भरता का एक विशिष्ट संस्करण भी स्थापित कर सकते हैं:

  yarn install {blah}@1.5

यह लंबे समय में अधिक ठीक-ट्यूनिंग और कम सिरदर्द के लिए अनुमति देता है।

@ k0pernikus - आपकी विस्तृत प्रतिक्रिया के लिए धन्यवाद। सबसे पहले, मुझे दो मुद्दों को स्वीकार करने के लिए माफी मांगनी चाहिए - # 4476 मेरे कुछ वर्कफ़्लो को चला रहा है। तथ्य यह है कि yarn upgrade कुछ हद तक टूटा हुआ प्रतीत होता है, इस मुद्दे से कोई लेना देना नहीं है, निश्चित रूप से।

वर्कफ़्लो के लिए, मैं कल्पना नहीं कर सकता कि केवल एक ही टीम है जहाँ एक डेवलपर नई निर्भरता बनाए रखने / परीक्षण करने का प्रभारी है, जबकि अन्य डेवलपर कोड बेस पर काम करते हैं। मेरे पास जो बड़ा मुद्दा है जो शुरू हुआ है, वह यह है कि मैं नई निर्भरताएं स्थापित / परीक्षण करूंगा, हर किसी को yarn install चलाने के लिए कहूंगा और फिर 4-5 प्रश्न प्राप्त करूंगा यदि परिवर्तित yarn.lock को प्रतिबद्ध होना चाहिए। । ऐसा लगता है कि मैं एक बदतर जगह पर होऊंगा अगर मैंने कहा "अगर लॉकफाइल बदलता है, तो इसे कमिट करें" क्योंकि उस बिंदु पर मैं एक कमिट लॉक के लिए समाप्त हो सकता है जो कुछ इस तरह दिखता है:

• यार्न बदल दिया (देव 4)
• यार्न बदल दिया (देव 3)
• यार्न बदल दिया (देव 2)
• यार्न बदल दिया (देव 1)
• अद्यतित निर्भरताएँ (मुझे)

हालाँकि, यह ऐसा हो सकता है कि जिस तरह से यार्न काम करने का इरादा रखता है, उसी तरह मेरी टीम की परियोजनाओं के लिए हम अपने सभी रेपो में जमे हुए लॉकफाइल का उपयोग करेंगे ताकि केवल add और upgrade कारण बने बदलने के लिए ताला।

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

@artlogic हमारी टीम के पास --install.pure-lockfile true प्रोजेक्ट के .yarnrc का बिलकुल इसी कारण से है।

@jboler - मैंने पहले उस सेटिंग को नहीं देखा था। मैं एक नज़र लेने जा रहा हूं, लेकिन ऐसा लग रहा है कि मैं यह सुझाव दूंगा कि हम अपने सभी रेपो के लिए .yarnrc जोड़ दें, और मेरे पास जितने भी FOSS प्रोजेक्ट हैं, उनके सभी रिपोज।

यदि यार्न टीम का कोई व्यक्ति पुष्टि कर सकता है कि इरादा yarn install और हर रन पर लॉक फ़ाइल को बदल देगा (निर्भरता में कोई बदलाव नहीं होने के बावजूद) तो मैं इस मुद्दे को बंद कर दूंगा।

देर से प्रतिक्रिया के लिए @artlogic क्षमा करें।

बात यह है, यह __ अप्रत्याशित__ है कि लॉक फ़ाइल को संभावित रूप से बदलने के लिए yarn install । मैं जानता हूं कि यह आदर्श नहीं है और इसे बेहतर संचार की जरूरत है। मैं वास्तव में एक बेहतर डिफ़ॉल्ट बनाना चाहता हूं, लेकिन इस बीच, मुझे लगता है कि @jboler जैसा कुछ सुझाया गया है, लेकिन शायद --frozen-lockfile उपयोग करना, तब तक सबसे अच्छा समाधान होगा जब तक हम यह पता नहीं लगा लेते हैं कि यार्न को विभिन्न परिदृश्यों के तहत कैसे व्यवहार करना चाहिए जैसे कि वर्कफ़्लोज़ जहां लोग yarn add आदि का उपयोग करने के बजाय निर्भरता अपडेट करने के लिए package.json संपादन करना पसंद करते हैं।

@BYK मैं हूं । यह व्यवहार बहुत भ्रामक है:

मेरे पास जो बड़ा मुद्दा है जो शुरू हुआ है वह यह है कि मैं नई निर्भरता स्थापित / परीक्षण करूंगा, सभी को यार्न स्थापित चलाने के लिए कहूंगा और फिर 4-5 प्रश्न प्राप्त कर सकता हूं कि क्या परिवर्तित यार्न के लिए प्रतिबद्ध होना चाहिए।

हमारी टीम में ~ 50 लोग शामिल हैं जो हर दिन yarn install चलाते हैं :(

@vkrol आपको .yarnrc फ़ाइल में चेक करने में सक्षम होना चाहिए, जिसमें --install.frozen-lockfile true या --install.pure-lockfile true तक के मुद्दों से बचने के लिए जब तक कि यार्न अपना व्यवहार नहीं बदलता। क्या वह मदद करेगा?

@ NYK pure-lockfile हमारी मदद करेंगे, लेकिन frozen-lockfile । अगर मैं सही ढंग से समझता हूं कि yarn install एक त्रुटि के साथ विफल हो जाएगा यदि जमे हुए-लॉकफाइल सक्षम है। यह व्यवहार हमारे मामले में बिल्कुल अस्वीकार्य है।

@vkrol मेरी प्राथमिकता frozen-lockfile क्योंकि यह केवल तभी विफल होगा जब आपकी लॉक फ़ाइल को बदलने की आवश्यकता हो और संगत न हो। pure-lockfile आपके पास बेकार या बहुत गलत होने के करीब एक ताला हो सकता है लेकिन आपको अभी भी असफलता नहीं मिलेगी। यार्न बस आंतरिक प्रस्तावों का उपयोग करेगा जो इसे खुशी से गणना करता है। यदि आपकी टीम के सभी सदस्य यार्न के सटीक समान संस्करण का उपयोग करते हैं, तो यह ठीक होना चाहिए। यदि नहीं, तो यह खतरनाक हो सकता है।

@ NYK शायद मैं frozen-lockfile के व्यवहार को सही ढंग से नहीं समझता। क्या यह विफल हो जाता है जब लॉकफाइल पैकेज.जोन सामग्री के अनुरूप होता है, लेकिन कुछ आंतरिक अनुकूलन की आवश्यकता होती है?

@vkrol विफल नहीं होना चाहिए जब फ़ाइल को आगे अनुकूलित किया जा सकता है लेकिन यह package.json के अनुरूप है और अपने आप में सुसंगत है। यदि नहीं, तो यह एक बग है। इसके लिए एक परीक्षण भी है: https://github.com/yarnpkg/yarn/blob/0415b07b3293ab125a77f3f66fe14034d6e5b376/__tests__-commands/install/lockfiles.js#L72 -L84 -L84

@ NYK मैं इसके बारे में नहीं जानता था। मैं इस विकल्प की कोशिश करूँगा, धन्यवाद! मुझे लगता है कि इस तथ्य को कहीं दस्तावेज होना चाहिए।

@BYK

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

मुझे इस झंडे के इस्तेमाल में कुछ कमी नजर आई। यदि यार्न.लॉक को इस कमांड के बार-बार किए गए इनवोकेशन से अनुकूलित किया जा सकता है तो yarn install --frozen-lockfile इस ध्वज के बिना "अखंडता" चेक के माध्यम से अनुकूलित नहीं हैं। यह एक बग? क्या मुझे अलग मुद्दा बनाने की आवश्यकता है?

@BYK आपकी प्रतिक्रिया के लिए धन्यवाद। मेरी टीम की परियोजनाओं के लिए, अब हम frozen-lockfile का उपयोग कर रहे हैं और चीजें ठीक (अपेक्षाकृत) काम कर रही हैं। हालाँकि यह मुद्दा मेरे लिए चिंता का विषय है। विशेष रूप से अनावश्यक अनुकूलन यार्न yarn install चलने पर लॉक फ़ाइल के लिए बना रहा है।

यहाँ स्पष्ट उदाहरण मैं दे सकता हूँ जहाँ यह व्यवहार समस्याओं का कारण बनता है:

1. मैं yarn add [blah] का उपयोग करके एक नई निर्भरता जोड़ता हूं और अपने अपडेट किए गए package.json और yarn.lock वचन देता हूं।
2. मेरे पैकेज में योगदानकर्ताओं ने परिवर्तनों को नीचे खींचा और देखा कि yarn.lock अपडेट किया गया है, और इस प्रकार yarn install चलते हैं।
3. कुछ मामलों में ये योगदानकर्ता इंस्टॉल के बाद एक संशोधित yarn.lock साथ समाप्त होते हैं। इस मामले में उन्हें क्या करना चाहिए? क्या यह देखने की दौड़ है कि पुल अनुरोध को पहले कौन जमा कर सकता है?

स्पष्ट होने के लिए, मुझे yarn install yarn.lock संशोधित करने में कोई समस्या नहीं है यदि package.json संशोधित किया गया है। मेरी समस्या अनुकूलन है जब package.json को बदला नहीं गया है। मैं तीन संभावित समाधान देखता हूं:

1. किसी भी परियोजना को निर्देशित करें जो निर्भरता को केंद्र में --install.frozen-lockfile true को .yarnrc फ़ाइल जोड़ने के लिए प्रबंधित करता है। यह संभवतः बहुत सारी परियोजनाएं होंगी - अधिकांश एनपीएम पैकेज जो मुझे लगता है।
2. ऐड चरण के दौरान लॉक फ़ाइल को अनुकूलित करने के लिए यार्न को मजबूर करने के लिए एक स्विच प्रदान करें, जैसे yarn add --optimize [blah] । फिर डायरेक्ट पैकेज मेंटेनर हमेशा उस स्विच का उपयोग करते हैं।
3. स्थापित चरण के दौरान yarn.lock अनुकूलन करने से यार्न को अस्वीकार करें जब तक package.json अद्यतन नहीं हुआ।

मैं विकल्प 3 की वकालत कर रहा हूं, लेकिन मैं विकल्प 2 को एक उचित विकल्प के रूप में भी देख सकता था।

आपके समय के लिए धन्यवाद!

मुझे यह विचार पसंद है कि yarn install yarn.lock फ़ाइल को अपडेट नहीं करता है, बल्कि यह कहकर चेतावनी देता है कि "आपका यार्न .लॉक फ़ाइल पुराना है, yarn blah चलाएं इसे अभी अपडेट करें `।

@BYK क्यों ~ नहीं करता है ~ यार्न लागू करने के लिए yarn.lock yarn install बजाय अनुकूलन करता है जब add / upgrade चलाए जाते हैं?

संपादित करें: ठीक टाइपो

@ स्पेंसर-ब्राउन: मैंने जो देखा है उसके आधार पर, यह वास्तव में इंस्टॉल पर अनुकूलन लागू करता है - यही मैं समस्याग्रस्त पाता हूं

यार्न के लिए अनुकूलन नहीं होना चाहिए। यार्न ऐड पर चलाया जाना चाहिए? यार्न.लॉक वैसे भी बदलता रहेगा। यह @artlogic की हालिया टिप्पणी में विकल्प नंबर दो है, है ना? अनुकूलन तब क्यों नहीं होता है, इसलिए किसी और को किसी अन्य यार्न को बदलने की आवश्यकता नहीं होती है?

@artlogic उफ़, टाइपो :) - मेरी टिप्पणी को "करना" कहना चाहिए; संपादित।

हम संगीतकार का उपयोग करते हैं और composer install कभी भी लॉक फ़ाइल को नहीं छूते हैं।

composer update या composer require ( yarn add बराबर) लॉक फ़ाइल में किए जाने वाले किसी भी परिवर्तन या अनुकूलन के लिए चलाया जाना चाहिए।

कई वर्षों में, हमें कभी भी composer install अस्पष्ट व्यवहार के बारे में चिंता करने की ज़रूरत नहीं है।

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

हम संगीतकार का उपयोग करते हैं और composer install कभी भी लॉक फ़ाइल को नहीं छूते हैं।

composer update या composer require ( yarn add बराबर) लॉक फ़ाइल में किए जाने वाले किसी भी परिवर्तन या अनुकूलन के लिए चलाया जाना चाहिए।

कई वर्षों में, हमें कभी भी composer install अस्पष्ट व्यवहार के बारे में चिंता करने की ज़रूरत नहीं है।

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

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

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

मुझे लगता है कि yarn install --pure-lockfile डिफ़ॉल्ट होना चाहिए, और वर्तमान व्यवहार प्राप्त करने के लिए --fix-my-dev-process-inconsistencies-for-me-magically विकल्प हो सकता है।

@ryancastle --pure-lockfile आपको यह नहीं बताएगा कि अपडेट आपके लॉकफ़ाइल के लिए है। यह केवल एक उत्पन्न नहीं करता है। यह अभी भी अप्रत्याशित व्यवहार को जन्म दे सकता है। यदि अपडेट की आवश्यकता है तो --frozen-lockfile विफल हो जाएगा।

मैं थोड़ी देर के लिए --install.frozen-lockfile true अपने .yarnrc के साथ काम कर रहा हूं और यह समझदारी से काम करता है। ट्रिक रेपो के लिए शुरुआती yarn.lock बनाने की है, ताकि उस झंडे के बिना प्रभाव न हो। एक बार बनने के बाद, इंस्टॉल yarn.lock नहीं बदल सकते हैं, लेकिन अपडेट कर सकते हैं। एक बार जब मैंने इस वर्कफ़्लो का उपयोग करना शुरू कर दिया तो yarn.lock लिए आकस्मिक परिवर्तनों की संख्या शून्य हो गई।

@artlogic Sidenote: मेरे पास frozen-lockfile true मेरे .yarnrc रूप में अच्छी तरह से था, अब मैं इसे केवल बिल्ड सर्वर पर लागू करता हूं, क्योंकि हम मुद्दों में भाग लेते थे yarn.lock लिए जानबूझकर परिवर्तन package.json से yarn.lock सिंक करने का प्रयास किया जा रहा है, क्योंकि एक डेवलपर ने मैन्युअल रूप से package.json उपयोग किया या निर्भरता जोड़ने के लिए npm का उपयोग किया।

देखें: https://github.com/yarnpkg/yarn/issues/4570

@ k0pernikus का उपयोग करने का मामला यह है कि हमने --frozen-lockfile yarn install साथ डिफ़ॉल्ट क्यों नहीं बनाया है। मुझे ईमानदारी से पता नहीं है कि लोगों को बाधा डालने के बिना एक अच्छा समझौता क्या होगा, जो package.json संपादन करते हैं और फिर लॉकफ़ाइल को अपडेट करने के लिए yarn install चलाते हैं। मैंने yarn sync जैसे एक झंडे या एक नई कमान का प्रस्ताव किया, लेकिन इस विचार को लागू करने से पहले समुदाय द्वारा खारिज कर दिया जाना चाहिए।

इसके अलावा, यह एक ब्रेकिंग परिवर्तन होगा, इसलिए इसे यार्न 2.x की आवश्यकता होगी :)

एक ध्वज या यार्न सिंक जैसी एक नई कमान

मुझे अच्छा लगता है 👍 और yarn install एक नोटिस दिखा सकता है "package.json और यार्न .lock सिंक से बाहर हैं। लॉकफ़ाइल को अपडेट करने के लिए 'यार्न सिंक चलाएं"

मुझे ईमानदारी से पता नहीं है कि संकुल को संपादित करने वाले लोगों को बाधित किए बिना एक अच्छा समझौता क्या होगा। लॉज को अपडेट करने के लिए यार्न को स्थापित करें और फिर यार्न स्थापित करें।

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

मैंने यार्न सिंक की तरह एक ध्वज या एक नई कमान का प्रस्ताव किया था, लेकिन इस विचार को लागू करने से पहले समुदाय द्वारा खारिज कर दिया जाना चाहिए।

मेरे लिए, यह एक उचित समझौता जैसा लगता है। यदि आप अपने package.json संपादित करने पर जोर देते हैं, तो चीजों को वापस सिंक में लाने के लिए एक कमांड चलाना समझ में आता है।

यहाँ मैं देखना चाहूंगा:

• yarn install बिना yarn.lock yarn.lock बनता है।
• yarn install yarn.lock इसे संशोधित नहीं करता है। यदि यह पता चलता है कि yarn.lock और package.json बीच कोई विसंगति है, तो एक त्रुटि वापस आ जाती है (जैसे @indeyets इंगित की गई)।
• yarn sync (या शायद yarn install -s ) yarn.lock package.json साथ सिंक में वापस मिल जाता है।

मुझे अभी भी एक अंतर्निहित चिंता है कि yarn install yarn.lock तब भी संशोधित करता है जब package.json लॉक फ़ाइल के साथ सिंक से बाहर न हो। आप ऊपर देखेंगे कि यह कुछ "अनुकूलन" करता है। क्या बिना ब्रेकिंग परिवर्तन के इस व्यवहार को कम से कम अक्षम करना संभव होगा?

मुझे अभी भी एक अंतर्निहित चिंता है कि यार्न स्थापित यार्न को संशोधित करता है। यहां तक ​​कि जब पैकेज।जॉन लॉक फ़ाइल के साथ सिंक से बाहर नहीं होता है। आप ऊपर देखेंगे कि यह कुछ "अनुकूलन" करता है। क्या बिना ब्रेकिंग परिवर्तन के इस व्यवहार को कम से कम अक्षम करना संभव होगा?

यहाँ भी वही भाव। मुझे लगा कि इस मुद्दे के खुले रहने का यह विशिष्ट कारण है। जैसा कि # 4147 में "सिंक" पर चर्चा की जा रही है

इसीलिए मैंने इस मुद्दे को पहले स्थान पर खोजा।

क्या हम इसे और # 4147 मर्ज करेंगे?

@ एनवाईके मुझे लगता है कि यहां चर्चा की गई सभी लगभग # 4147 के साथ विलय की जा सकती है। जैसा कि मैंने पहले कहा है, मुझे लगता है कि केवल एक चीज जो मुझे अभी भी चिंतित करती है वह है "अनुकूलन" कि yarn install yarn.lock पर प्रदर्शन करती है, भले ही कोई परिवर्तन package.json ।

मेरा विचार है कि यार्न 2.0 के रास्ते पर एक स्टॉप-गैप के रूप में, इन अनुकूलन को अक्षम किया जाना चाहिए। मुझे नहीं लगता कि यह ब्रेकिंग चेंज होगा।

मैं @artlogic से 100% सहमत

मैं CircleCI की स्थापना कर रहा था और मेरा निर्माण विफल हो रहा था और मैंने इसे yarn.lock साथ एक कैशिंग मुद्दे पर सभी तरह से ट्रेस किया। रेल से आ रहा है, मुझे उम्मीद है कि लॉक फ़ाइल एक इंस्टॉल्ड कमांड द्वारा लॉक की जाएगी।

सर्किल पर कैश चेकिंग के लिए यह सुझाव दिया जा रहा है: https://circleci.com/docs/2.0/yarn/

#...
      - restore_cache:
          name: Restore Yarn Package Cache
          keys:
            - yarn-packages-{{ checksum "yarn.lock" }}
      - run:
          name: Install Dependencies
          command: yarn install
      - save_cache:
          name: Save Yarn Package Cache
          key: yarn-packages-{{ checksum "yarn.lock" }}
          paths:
            - ~/.cache/yarn
#...

यह कभी भी काम नहीं करेगा क्योंकि यार्न बदल सकता है, जब यह नहीं होना चाहिए।

FYI करें, यार्न 1.10.1 पर macOS 10.13.6 के तहत, मैंने अभी-अभी ओपी के बग उत्तेजना की कोशिश की, और पाया कि यार्न .lock को बदल दिया गया था। दूसरे शब्दों में, जब मैंने कोशिश की:

yarn init
yarn add cordova
cp yarn.lock yarn.lock.initial
rm -r node_modules
yarn install
diff yarn.lock.initial yarn.lock

इसलिए, यार्न 1.10.1 का उपयोग करते समय, yarn install ने yarn.lock नहीं बदला, जैसा कि ओपी ने यार्न 1.0.1 का उपयोग करते समय किया था। (मैं इसे एक अच्छी बात मानता हूं, जैसा कि मुझे लगता है कि ओपी होगा।)

@dtgriscom यह बहुत अच्छा है कि समस्या कॉर्डोवा के लिए अब और नहीं हो रही है! मैं सोच रहा था कि यह पूरी तरह से तय हो गया है या यदि यार्न अभी भी स्थापित करने पर लॉक फ़ाइल को अनुकूलित करने का प्रयास कर सकता है?

यह जानना अच्छा होगा, है ना? आपने नोट किया कि समस्या पैकेज-विशिष्ट थी; यह समझ में आता है कि यह संस्करण-विशिष्ट भी हो सकता है। (मैंने "हम ऐसा कुछ बदलना चाहते हैं जिसे बदलना नहीं चाहिए" का औचित्य कभी नहीं सुना; "हम अनुकूलन कर रहे हैं" के अलावा ...)

मैं तहे दिल से सहमत हूँ कि एक install ऑपरेशन को डिफ़ॉल्ट रूप से नियतात्मक होना चाहिए। .lock फ़ाइल का अद्यतन करने के लिए डेवलपर को एक क्रिया करने की आवश्यकता होती है, जिसे वह जानता है कि फ़ाइल में परिवर्तन उत्पन्न करेगा। उदाहरण के लिए, आप yarn install --optimize जैसा कुछ चला सकते हैं जो छोटे अनुकूलन के लिए अनुमति देता है जो संकुल की वर्तमान स्थिति को नहीं तोड़ता है।

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

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

मैं लोगों को बता रहा हूं कि लॉक फ़ाइल में परिवर्तन सहित PRs को मर्ज नहीं किया जाएगा क्योंकि नए या अद्यतन निर्भरता को जोड़ने पर लॉक फ़ाइल को केवल बदल दिया जाता है। यह वही है जो स्थापित प्रलेखन बताता है:

yarn install

स्थानीय node_modules फ़ोल्डर में package.json भीतर सूचीबद्ध सभी निर्भरताएं स्थापित करें।

yarn.lock फ़ाइल निम्नानुसार उपयोग की जाती है:

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

यदि आप yarn.lock सुनिश्चित करना चाहते हैं --frozen-lockfile ।

क्या दस्तावेज़ीकरण गलत है क्योंकि ये अनुकूलन हैं जो ऊपर कहा जा सकता है या क्या यह समय के लिए ध्यान में रखने के लिए एक बग है?

ps। यह अभी भी होता है, और yarn --frozen-lockfile विफल नहीं होता है जब यह करता है।

मैं अपने .yarnrc फ़ाइल में --frozen-lockfile का उपयोग कर रहा हूं, जो विभिन्न मशीनों पर yarn install चलने पर यार्न को संशोधित करने से प्रभावी ढंग से रोकते हैं। लेकिन यह भी मेरे यार्न.लॉक को संशोधित करने से yarn add blahblah को रोकता है। क्या यह सही व्यवहार है या मुझे कुछ याद आ रहा है? मैंने पूरा धागा पढ़ा है और यह मुझे लगता है कि --frozen-lockfile अब के लिए अनुशंसित दृष्टिकोण है?

@konekoya हाँ, आप सही हैं कि आप वर्तमान में उपयोग करना चाहिए

yarn install --frozen-lockfile

और .yarnrc में सेटिंग पर भरोसा नहीं कर सकता क्योंकि यह आपके yarn.lock को कभी भी अपडेट करने से रोकेगा।

आपके .npmrc और .yarnrc आपकी सामग्री के आधार पर आप उपयोग करने में सक्षम हो सकते हैं

yarn install --no-default-rc {dependency}

लेकिन मैं उस पर भरोसा नहीं करूंगा (क्योंकि जैसे ही आप अपने आरसी-फाइलों में अन्य सेटिंग्स होंगे)।

मेरी टिप्पणी और प्रासंगिक मुद्दा देखें: # 4570, esp। मेरा निष्कर्ष ।

कि @ k0pernikus को साफ़ करने के लिए धन्यवाद। तुमने मेरा दिन बना दिया :)

@BYK क्यों यार्न के लिए अनुकूलन लागू होता है yarn.lock पर yarn install के बजाय जब add / upgrade चलाए जा रहे हैं?

मुझे लगता है कि @ स्पेंसर-ब्राउन की टिप्पणी यहाँ इस समस्या को "ठीक" करने के लिए महत्वपूर्ण है। मैंने सिर्फ अपने लिए परीक्षण किया है और yarn upgrade चल रहा है और फिर yarn मुझे "पहले से ही अद्यतित" बताया गया था। इसलिए मैंने अपने node_modules नष्ट कर दिया और yarn भाग लिया, जिसके परिणामस्वरूप "अनुकूलित" लॉकफ़ाइल हुआ, जो कि मेरे प्रोजेक्ट के अन्य देवों ने समाप्त कर दिया होगा यदि मैंने yarn upgrade ।

अब अगर yarn upgrade (और yarn add ) yarn install के समान अनुकूलन चलाएंगे तो हमें यह समस्या नहीं होगी। किसी भी मौजूदा कार्यक्षमता को नहीं तोड़ने के बारे में बहुत सारी बातें हुई हैं और मैं yarn upgrade और yarn add कुछ भी तोड़ने के बाद अनुकूलन को नहीं देख रहा हूं - बस इसे थोड़ा धीमा कर रहा हूं।

वर्कअराउंड के रूप में मैं अपने सभी देवों को नोड_मॉड्यूल्स को हटाने के निर्देश देने के बारे में सोच रहा हूं, जब भी उन्हें लॉकफ़ाइल्स को दूसरों पर धकेलने से पहले "अनुकूलन" को लागू करने के लिए लॉकफ़ाइल को अपडेट करने की आवश्यकता होती है। या हो सकता है कि वे yarn upgrade && yarn prune चला सकें - शायद वह चाल चलेगा?

वर्कअराउंड के रूप में मैं अपने सभी देवों को नोड_मॉड्यूल्स को हटाने के निर्देश देने के बारे में सोच रहा हूं, जब भी उन्हें लॉकफ़ाइल्स को दूसरों पर धकेलने से पहले "अनुकूलन" को लागू करने के लिए लॉकफ़ाइल को अपडेट करने की आवश्यकता होती है। या हो सकता है कि वे yarn upgrade && yarn prune चला सकते हैं - शायद यही चाल चलेंगे

अपडेट: आप मैन्युअल रूप से prune नहीं चला सकते हैं, आपको बस यह संदेश मिलता है: _ "prune कमांड आवश्यक नहीं है। yarn install extuneous पैकेजों को prune करेगा" ।_ और जब से आप नहीं चला सकते हैं क्योंकि आप स्थापित नहीं करते हैं। are \ _ "पहले से ही अद्यतित" _ मुझे लगता है कि हम nun_modules हटाने के साथ जा रहे हैं और फिर प्रूनिंग करने के लिए yarn रहे हैं।

मेरे लिए, yarn लिए सबसे बड़ा विक्रय बिंदु पूर्वानुमेय, विश्वसनीय लॉक फ़ाइल व्यवहार है। yarn install पर लॉक फ़ाइल को बदलने से मुझे वास्तविक चिंता होती है।

मेरे लिए, yarn लिए सबसे बड़ा विक्रय बिंदु पूर्वानुमेय, विश्वसनीय लॉक फ़ाइल व्यवहार है। yarn install पर लॉक फ़ाइल को बदलने से मुझे वास्तविक चिंता होती है।

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

यह वास्तव में अविश्वसनीय है। दूसरों ने पहले ही इसे अच्छी तरह से बताया है। एक लॉक फ़ाइल को इंस्टॉल पर नहीं बदलना चाहिए। यह नकारात्मक प्रभाव वर्कफ़्लो को प्रभावित करता है। हमारी टीम में हर डेवलपर जानता है कि किन परिस्थितियों में लॉकफ़ाइल को बदलने की अनुमति है। जब निर्भरता को अद्यतन किए बिना लॉकफ़ाइल बदलता है, तो यह अनावश्यक भ्रम और अतिरिक्त जाँच का कारण बनता है। यह बेसिक पैकेज मैनेजर UX है जो अभी टूटा हुआ है। कृपया ठीक करें।

मैं सिर्फ इस व्यवहार, से हैरान हो गया जब Node.js 13 से 14 तक सभी मेरी चलती yarn.lock बदल गया जब एक कर फ़ाइलें yarn install और मैं सोच रहा था क्यों ...

मुझे लगता है कि उपयुक्त व्यवहार अगर किसी भी तरह से yarn.lock _optimizing_ को चेतावनी देने का होगा।