<p>यार्न शायद कैश पथ को फ़ाइल पथ के साथ हल नहीं करना चाहिए</p>

इसने मुझे भी बेवकूफ बनाया। सभी कैश को साफ़ किए बिना इसके आसपास जाने का एक तरीका होना चाहिए।

मुझे लगता है कि इस मामले के लिए यार्न को उपयोगी बनाने के तीन तरीके हो सकते हैं:

1. सभी स्थानीय निर्भरता को नजरअंदाज करने का सुझाव @donaldpipowitch ।
2. स्थानीय निर्भरता को फिर से स्थापित करना अगर इसमें कोई फ़ाइल बाद में संशोधित की जाती है जब इसे कैश किया जाता है। इसके लिए हमें इस मेटाडेटा को रखना होगा। स्थानीय निर्भरता के लिए हम "रिज़ॉल्व्ड" कॉलम में इस तरह की लाइनें डाल सकते हैं: file://<path>@<cache_timestamp>
3. yarn cache rm <package> और yarn cache add <package> जैसे आदेशों के साथ संकुल नामों को अनदेखा करना। सभी निर्भरता के लिए।

मैं दूसरा सुझाव लागू करना चाहता हूं। जब तक, तीसरा विकल्प अन्य मामलों के लिए भी उपयोगी हो सकता है। उदाहरण के लिए, पहले से ही कैश की गई निर्भरता के लिए कैश को रीफ्रेश करने के लिए yarn cache add <package> का उपयोग किया जा सकता है, जब कोई निर्भरता डाउनलोड करते समय कुछ गलत हो सकता है।

@hantuzun स्थानीय निर्भरता को कैश क्यों करता है? वे स्थानीय रास्ते हैं, इसलिए यह तेजी से कैश होगा या नहीं।

@ satya164 आप सही कह रहे हैं। हालाँकि, मैं तीसरे दृष्टिकोण के लिए अधिक इच्छुक हूं यदि नेटवर्क से एक निर्भरता जानबूझकर संशोधित की जाती है।

yarn cache ignore <package> जैसा कुछ उपयोगी होगा। लेकिन मुझे लगता है कि वे पारस्परिक रूप से अनन्य नहीं हैं। पैकेज को अनदेखा करना उपयोगी है, लेकिन इसके लिए मैनुअल काम की आवश्यकता होती है। यदि उन्हें डिफ़ॉल्ट रूप से अनदेखा किया गया तो फ़ाइल निर्भरता को बिना किसी अतिरिक्त प्रयास के काम करने के लिए बनाया जा सकता है।

क्या कोई मुझे आंतरिक तर्क समझा सकता है?

मेरी समझ:
जब file: साथ एक निर्भरता file-resolver.js मिलती है। यह कहता है कि निर्भरता की प्रतिलिपि बनाई जानी चाहिए और हैशेड नहीं है। नहीं हैश का मतलब यह नहीं है कि इसे पहले से ही कैश नहीं किया जाना चाहिए ...? लेकिन copy-fetcher.js हैश को null रखने के बजाय खाली स्ट्रिंग में सेट करता है ... क्या यह समस्या है?

@bestander या @kittens शायद आप इसे थोड़ा और समझा सकते हैं ...? PR ♥ बनाने में थोड़ी मदद करना पसंद करेंगे

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

आप शायद एक पीआर के साथ शुरू कर सकते हैं जो एक टूटी हुई इकाई परीक्षण जोड़ता है

ठीक है, आपकी प्रतिक्रिया के लिए धन्यवाद। क्या मुझे आपको पीआर में एक समीक्षक के रूप में पिंग करना चाहिए या मुझे किसी और (या किसी को) को पिंग करना चाहिए ...?

हाँ, मुझे पिंग

@bestander शायद यह मुद्दा बंद नहीं होना चाहिए क्योंकि यह अभी तक तय नहीं है?

हां, इसे फिर से खोला जाना चाहिए। इसे बंद कर दिया गया क्योंकि मैंने अपने पीआर के शीर्षक में "फिक्स # 2165" लिखा था। शुरुआत में मैंने सोचा था कि यह एक चालू पीआर होगा, लेकिन इस बग को ठीक करने के लिए हम दो पीआर चाहते हैं: पहले वाले ने एक यूनिट टेस्ट जोड़ा (यह दावा जो विफल होगा वह वास्तव में सक्रिय नहीं है, इसलिए सीआई नहीं उड़ा) और दूसरा वास्तव में इसे ठीक कर देगा।

क्षमा करें, जब PR विलय हो जाता है, तो github मुद्दों को बंद कर देता है

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

मेरे एस्लिंट-कॉन्फ़िगरेशन-बेस-एस्लिंट पैकेज की सामग्री का संपादन

yarn cache clean && rm -rf node_modules/eslint-config-base-eslint && yarn install --force && yarn lint

परियोजना में योगदान देने के लिए सभी का स्वागत है।
यह कुछ भी हो सकता है - इस मामले के लिए एक टूटी हुई एकीकरण परीक्षण सबमिट करना, एक फिक्स या किसी को फिक्स पर काम करने के लिए आश्वस्त करना।
यदि आप उस दृष्टिकोण के सर्वोत्तम तरीके के बारे में चैट करना चाहते हैं, तो आप डिस्क चैनल पर मदद पा सकते हैं।

मुझे वास्तव में लगता है कि फिक्स कोड की 10-15 पंक्तियां होनी चाहिए, यह शायद इसे ठीक करने में बहुत समय बचाएगा

FYI करें: यह हो सकता है कि यह मुद्दा linking dependencies धीमी https://github.com/yarnpkg/yarn/issues/1496#issuecomment -282688818

माफ़ करना। मुझे इस मुद्दे के लिए एक और पीआर बनाने का समय नहीं मिला :( मैं (और अभी भी) बहुत व्यस्त था।

@bestander यह मेरे लिए एक बहुत बड़ा अवरोधक है, जो मल्टी-मॉड्यूल प्रोजेक्ट पर काम कर रहा है। अगर मैं @donaldpipowitch के कोड लिंक और टिप्पणियों को सही ढंग से पढ़ रहा हूं, तो क्या हर बार जब हम इसे हल करने की कोशिश करते हैं तो फाइल-रिसॉल्वर एक नया hash (शून्य के बजाय) बना सकता है? UUID कहें या वर्तमान टाइमस्टैम्प? मुझे माफ कर दो अगर मुझे कुछ याद आ रहा है, तो मैं कोड के काम करने के तरीके से परिचित नहीं हूं।

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

Tue, 7 Mar 2017 को 03:38 पर, मैट ट्रायन्हम सूचनाएँ @ithub.com ने लिखा:

@bestander https://github.com/bestander यह एक बहुत बड़ा अवरोधक है
मेरे लिए, एक मल्टी-मॉड्यूल प्रोजेक्ट पर काम करना। अगर मैं @donaldpipowitch पढ़ रहा हूँ
https://github.com/donaldpipowitch के कोड लिंक और टिप्पणियां
सही ढंग से, हम फ़ाइल-रिज़ॉल्वर एक नया हैश (इसके बजाय) बना सकते थे
अशक्त) हर बार इसे हल करने की कोशिश करता है तो यह एक पुनर्स्थापना के लिए मजबूर करता है? एक यूयूआईडी कहो
या वर्तमान टाइमस्टैम्प? मुझे माफ कर दो अगर मुझे कुछ याद आ रहा है, तो मैं परिचित नहीं हूँ
जिस तरह से कोड काम करता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/yarnpkg/yarn/issues/2165#issuecomment-284612526 , या मूक
सूत्र
https://github.com/notifications/unsubscribe-auth/ACBdWDS3xSr8KNu1o9Zn8sA9xdO8pyHOks5rjNEmgaJpZM4LFbmf
।

@bestander आपकी पिछली टिप्पणी के बारे में: क्या फाइलों को कॉपी करने के बजाय इसे

@danrot विंडो को सिमलिंक के लिए एडमिन की आवश्यकता होती है।
यह भी नोड मॉड्यूल को खोजने के लिए नीचे की ओर गड़बड़ करता है

साइमलिंक भी .npmignore और उस तरह के सामान की उपेक्षा करता है। (जिसे वर्तमान में नजरअंदाज किया जा रहा है।

क्या इसके लिए कोई वर्कअराउंड है जो वर्तमान में पूरे कैश को क्लियर कर रहा है? दुर्भाग्य से कोई yarn cache rm package तरह का आदेश नहीं लगता है।

@ rhys-e मैं इस छोटी स्क्रिप्ट का उपयोग करता हूं:

#!/bin/sh
if [ $# != 1 ]
then
   echo Usage $0 package-name
   exit 1
else
    echo Reinstalling $1
fi

dir="node_modules/$1"

if [ -d $dir ]
then
    rm -fr $dir
fi

cache=`yarn cache dir`/npm-${1}*
#        echo $cache
rm -fr $cache && yarn install --force

किसी को भी बस की कोशिश की है yarn link सभी स्थानीय निर्भरता postinstall ? उचित निराकरण भूमि तक उचित समाधान जैसा दिखता है।

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

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

@lucdew लिंक मूल रूप से हुड के नीचे एक सिमलिंक बनाएगा, जिसका अर्थ है कि नवीनतम स्थानीय संस्करण का उपयोग किया जाएगा। लेकिन मुझे लगता है कि एक स्क्रिप्ट होने से, कि इंस्टॉलेशन से पहले कैश के विशिष्ट डिप्स को साफ करना सही समाधान है।

मैंने स्थानीय पैकेज में परिवर्तन के आसपास काम करने में विभिन्न संयोजनों का परीक्षण किया है। मूल पैकेज के तहत स्थापित संस्करण में अद्यतन नहीं किया जा रहा है ।/node_modules/। मुझे लगता है कि बस इसे हटाने के लिए आवश्यकता होगी ./node_modules/प्रथम:

yarn cache clean; yarn upgrade file:../<package>

कहने की जरूरत नहीं है, स्थानीय पैकेजों को अपडेट / अपग्रेड करने के लिए मैन्युअल रूप से ग्लोबल कैश को साफ करने के लिए जरूरी नहीं होना चाहिए।

@fungilation वर्कअराउंड के रूप में, आप स्थानीय निर्भरताएँ स्थापित करने के लिए

प्रति # 2860 और बाद के मर्ज https://github.com/yarnpkg/yarn/commit/7241de13bb236526fa439a2528fbed319f60ef24 , अब आप " file: प्रोटोकॉल निर्भरता के साथ" ताज़ा कर सकते हैं

yarn install --force

संपादित करें या विशेष पैकेज को अपग्रेड

yarn upgrade [file protocol package name]

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

मुझे यह भी स्पष्ट किया गया कि निर्भरता को जोड़ने के लिए एक सक्रिय RFC है, संभवतः link: प्रोटोकॉल के साथ। इसका अनुसरण यहां किया जा सकता है, https://github.com/yarnpkg/rfcs/pull/34।

@mtraynham अपने पुल अनुरोध के लिए धन्यवाद! Awesome यह कमाल है। किसी भी कारण से --force की आवश्यकता क्यों है? मुझे वर्तमान में यह पता नहीं है कि इसे ठीक से देखे बिना यह अभी क्या करता है :) बस पूछ रहा है, क्योंकि npm को --force ध्वज की आवश्यकता नहीं है और npm की तरह व्यवहार करना अच्छा होगा।

संपादित करें जैसा दिखता है yarn upgrade [dependency] काम करता है। मैं इंगित करना चाहता हूं, यह हमेशा लॉकफाइल को नहीं बदलता है, जो केवल पैकेज को दर्शाता है। जेसन संस्करण परिवर्तन। मैंने अपनी मूल पोस्ट अपडेट कर दी है, क्योंकि अपग्रेड शायद अधिक उपयुक्त है।

लघु संस्करण है, यार्न कैश-रिसॉल्वर के साथ कुछ भी नहीं करेगा यदि लॉकफाइल नहीं बदला, तो हमें लॉकफाइल चेक को छोड़ना होगा और कैश को पूछना होगा यदि कोई नया संस्करण है। यह upgrade या install --force का उपयोग करके किया जा सकता है

yarn install --force प्रलेखन

"यह सभी पैकेजों को फिर से लिखता है, यहां तक ​​कि जो पहले स्थापित थे"।

यह वास्तव में इसका मतलब है कि यह लॉकफाइल अखंडता जांच को छोड़ देगा। अगर आप पैकेज को नहीं बदलते हैं तो लॉकफाइल अखंडता जांच आम तौर पर पास होगी। जसन फ़ाइल और इनायत से जमानत न दें। इसे लंघन करने से कैश को लॉकफाइल के खिलाफ गुम / बेमेल निर्भरता की जांच करने के लिए कहता है, लापता होने पर उन्हें डाउनलोड करें और स्थानीय रूप से किसी भी नए / लापता निर्भरता को वापस कॉपी करें। फिर यह npm install / postInstall स्क्रिप्ट चलाता है।

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

तो क्या, यह हमारे लिए क्या मतलब है? मेरे पास एक परियोजना पर लगभग 60 निर्भरताएं हैं (कोणीय से वेबपैक तक), एक file: निर्भरता के साथ। एक दूसरे install --force , जहां मैं केवल स्थानीय निर्भरता को ताज़ा करना चाहता हूं, इसमें ~ 5 सेकंड ( yarn install 1.5

अगर कोई सीएलआई कमांड है तो लॉकफ़ाइल चेक को छोड़ कर केवल विशेष फ़ाइल निर्भरता के लिए कैश की जांच करें, तो यह और भी तेज़ होगा, लेकिन मुझे एक नहीं मिला है।

यह सब कहा जा रहा है, मैं अभी भी इसे एक बैंड-सहायता कहूंगा। इसे link: जैसे बेहतर समाधान द्वारा प्रतिस्थापित किया जा सकता है; मुझे नहीं लगता कि कोई भी वास्तव में स्थानीय निर्भरता को कैश करने की परवाह करता है। बहुत कम से कम, install --force या upgrade का उपयोग करने का जोड़ा ओवरहेड ज्यादातर लापरवाही है और अब आपको yarn cache clean; mv node_modules /tmp/ ।

बहुत बढ़िया जवाब। । इसको लिखने के लिए धन्यवाद।

यार्न के कैश से फ़ाइलों के साथ यार्न स्थानीय सिमली प्रोजेक्ट फ़ाइलों को अधिलेखित करता है? (क्योंकि ऐसा लगता है कि यही हो रहा है)

पीआर परिवर्तन अब फ़ाइल को अमान्य कर देगा: कैश में निर्भरता और स्थानीय रूप से नए संस्करण को कॉपी करें।

क्या इसका मतलब यह है कि जब भी मैं एक पैकेज के अंदर $ yarn कॉल करता हूं, जिसमें "foo": "file:../" निर्भरता के रूप में "file:../" एक नई प्रतिलिपि बनाई जाएगी?

उदाहरण के लिए मेरे पास कई उदाहरणों के साथ एक पैकेज है जो पैकेज भी हैं:

foo/
foo/examples/
foo/examples/example-1/
foo/examples/example-2/
foo/examples/example-3/
...
foo/examples/example-10/

और ऐसा लगता है कि मेरे पास यार्न कैश में foo 10 गुना है। मैं foo हर संस्करण परिवर्तन पर अपने उदाहरणों का परीक्षण भी करता हूं (और मेरे पास उस तरह से कॉन्फ़िगर किए गए कई मॉड्यूल हैं, न कि केवल foo ), इसलिए ऐसा लगता है कि मेरा यार्न कैश वर्तमान में _really_ quick बढ़ता है।

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

मुझे लगता है कि यह आपके कैश में बासी संस्करण होने से बेहतर विकल्प है।
यार्न 0.26 के साथ आप फ़ाइलों को कॉपी करने के बजाय सिमलाइन बनाने के लिए link: का उपयोग कर सकते हैं।
इसके अलावा हम ऐसे वर्कस्पेस पर काम कर रहे हैं जो सिम्लिंक निर्माण को स्वचालित करेगा, https://github.com/yarnpkg/yarn/issues/3294

हाँ, कार्यक्षेत्रों के लिए तत्पर हैं work

link: अभी तक npm के साथ काम नहीं करता है, है ना? (क्योंकि https://github.com/npm/npm/pull/15900 अभी भी खुला है।)

Npm 5 patchnote से , फाइलें अब file: सिंटैक्स के साथ स्वचालित रूप से सिमिलिंक हो जाती हैं:

npm install ./packages/subdir अब एक रेगुलर इंस्टॉलेशन के बजाय एक सिमलिंक बनाएगा। फ़ाइल: //path/to/tarball.tgz नहीं बदलेगा - केवल निर्देशिका सीमांकित हैं। (# 15900)

तो हाँ, npm के साथ कोई link ।

npm install ./packages/subdir अब एक रेगुलर इंस्टॉलेशन के बजाय एक सिमलिंक बनाएगा

किंडा दुर्भाग्यशाली सब कुछ कॉपी करने ( node_modules ) और .npmignore या files फ़ील्ड का सम्मान न करने के कारण फ़ाइल डिपों ने कभी भी ऐसा व्यवहार नहीं किया। अब यह सिमलिंक से भी बदतर है।

मुझे लगता है कि फ़ाइल: और लिंक: को और बेहतर बनाया जा सकता है, अलग-अलग रणनीतियाँ हैं जिनके अपने प्रो और कॉन्स हैं और यार्न को लोगों को एक चुनने की अनुमति देनी चाहिए।
उदाहरण के लिए knit RFC को रणनीतियों में से एक के रूप में लागू किया जा सकता है https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-yarn-knit.md

@bestander

मुझे लगता है कि यह आपके कैश में बासी संस्करण होने से बेहतर विकल्प है।

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

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

@nikdojo उपयोग यार्न link: के बजाय निर्भरता के लिए प्रोटोकॉल file: , यह सिमलिंक उपयोग करता है। इसे 0.26 में पेश किया गया था।

वैकल्पिक रूप से, यदि आपके पास कई अंतर-परियोजना निर्भरता हैं, तो कार्यस्थानों का उपयोग करना शुरू करें।

संकेत के लिए @mtraynham Thx, मैंने किसी भी जानकारी को आधिकारिक डॉक्स में link: प्रोटोकॉल खोजने की कोशिश की, लेकिन लगता है कि यह वहाँ नहीं है। अब कार्यक्षेत्रों के साथ प्रयोग करना।

@bestander btw जैसा कि आप जानते हैं, प्रतिक्रिया-

यह कभी हल नहीं हुआ था? आपको स्थानीय पैकेजों को जोड़ने के लिए लिंकलोकल (एनपीएम पैकेजों) का उपयोग करना होगा (जो स्थानीय फाइल सिस्टम से पैकेजों का उपभोग करते समय यार्न संचालित होता है - कैशिंग के बजाय विंडोज पर जंक्शनों या सिमिलिंक का उपयोग करना)। एक नया yarn install तब कैश से पुराने सामान के साथ सब कुछ ओवरराइट करता है और आपको फिर से लिंक करना शुरू करना होगा।

क्या हम कम वास्तुकला वाले अंतरिक्ष यात्री हो सकते हैं और बस स्थानीय पैकेजों को कैश नहीं कर सकते। यह मुद्दा अब 1.5 साल पुराना है, और मैं हर बार yarn add ../<another-local-package> चलने पर थक जाता हूं, मैं another-local-package में कुछ बदल देता हूं।

हाय @ फफूंदी
मैंने एक और संबंधित मुद्दा खोला है: # 6037

काम नहीं करता है
मैंने फ़ाइल App.js में डाल दी है
कंसोल.लॉग ('यहां हम हैं'), और यह आउटपुट नहीं हुआ।
फिर सभी फ़ाइलों को हटा दें और यह अभी भी कैश से आउटपुट बनाता है।
इससे कैसे बचा जाए?

यार्न वास्तव में मुझे इस मुद्दे पर विफल रहा है। इसे छोड़कर बाकी सभी चीजों के लिए यह बहुत अच्छा रहा।

मैं परीक्षण उद्देश्यों के लिए एक स्थानीय पैकेज का एक नया संस्करण स्थापित करने की कोशिश कर रहा हूं, और मैं पुराने पैकेज के साथ कोई फर्क नहीं पड़ता कि मैं क्या करता हूं।

मैंने कोशिश की:

1. यार्न कैश की सफाई ( yarn cache clean package-name )
2. yarn add ' --force साथ आईएनजी
3. node_modules/package-name और yarn add ing को फिर से निकालना
4. स्थानीय पैकेज के संस्करण संख्या और फ़ाइल नाम को अपडेट करना ( यार्न अभी भी पुराने संस्करण की सामग्री को स्थापित करता है , भले ही यह नए को स्थापित करने की रिपोर्ट करता है)
5. उपरोक्त सभी का संयोजन

यह हास्यास्पद है, और मैंने इस पर अपने दिन के लगभग 4 घंटे बिताए हैं।

हमें स्थानीय पैकेजों को विकसित करने और पुनर्स्थापित करने की क्षमता की आवश्यकता है । मैं .bin फ़ोल्डर में एक फ़ाइल स्थापित करने के लिए यार्न पर भरोसा कर रहा हूं, इसलिए yarn link प्रश्न से बाहर है।

@ यार्न डेवलपर्स: क्या आप एक स्थानीय पैकेज स्थापित करने में सक्षम हैं, उस स्थानीय पैकेज में बदलाव कर सकते हैं, और फिर दोबारा इंस्टॉल करके उन परिवर्तनों को प्रतिबिंबित कर सकते हैं?

@gregjacobs मुझे yarn install --force साथ सफलता मिली थी

@jonathantorley मैं सिर्फ इसे फिर से करने की कोशिश की के साथ --force और यह अभी भी यार्न 1.12.3 साथ काम नहीं करता

इस समस्या का सामना कर रहे अन्य लोगों के लिए: एक वर्कअराउंड जो मुझे वास्तव में काम करने के लिए मिलता था वह आश्रित पैकेज की संस्करण संख्या को बढ़ाने के लिए था। थोड़ा कष्टप्रद, और आपको इसे प्रत्येक परिवर्तन पर (जब तक आप इसे स्क्रिप्ट नहीं कर सकते) करना याद रखना होगा।

स्थानीय पैकेज स्थापित करते समय yarn को इस वर्कअराउंड की आवश्यकता नहीं होनी चाहिए

मैंने yarn upgrade MY_PACKAGE_NAME preinstall स्क्रिप्ट में जोड़ा, और यह नवीनतम NPM संस्करण में अच्छी तरह से अपग्रेड हुआ। (फिर भी, मुझे एनपीएम संस्करण को मैन्युअल रूप से टक्कर देने की आवश्यकता है)।

ऐसा लगता है कि yarn add file:PATH अब हमेशा नई सामग्री को यार्न 1.13.0 में अपग्रेड करते हैं।
yarn install अभी भी नहीं।

@leavesster अभी भी मेरे लिए नहीं है।

इसे अपडेट करने के लिए मुझे tgz का नाम बदलना होगा

link कमांड का उपयोग करने का प्रयास करें: https://yarnpkg.com/lang/en/docs/cli/link/

yarn add file:PATH ने मेरे लिए नई सामग्री को अपग्रेड नहीं किया। इसके अलावा, package.json और .npmignore में फाइलों का सम्मान नहीं किया जाता है।

यह आपके पैकेज के संस्करण को बदलने का काम करता है।

यदि आप package.json और .npmignore में फ़ाइलों का सम्मान करने के लिए yarn add file:PATH चाहते हैं, तो आपको अपने स्थानीय पैकेज निर्भरता में yarn pack चलाना होगा और फिर जहाँ आप इसे स्थापित करना चाहते हैं yarn add file:path-to-local-pacckage.tgz

link कमांड का उपयोग करने का प्रयास करें: https://yarnpkg.com/lang/en/docs/cli/link/

yarn link एक ही समस्या का जवाब देने का इरादा नहीं है। यह अच्छा नहीं है अगर कोई एनपीएम पैकेज चाहता है जैसे कि यह पैकेज में फाइलों का सम्मान करते हुए प्रकाशित किया गया था। json और .npmignore।

@leavesster अभी भी मेरे लिए नहीं है।

इसे अपडेट करने के लिए मुझे tgz का नाम बदलना होगा

मेरे पैकेज में कोई tgz , जिसे मैं वर्तमान परियोजना में जोड़ने के लिए yarn add file: PACKAGE_PAH का उपयोग करता हूं। मेरे पास अपने पैकेज में सिर्फ js कोड है। शायद tgz अभी भी गलत है?

मेरे लिए भी काम नहीं कर रहा है

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

मेरे पास @gregjacobs जैसा ही मुद्दा है। yarn cache clean package मदद नहीं की। लेकिन मुझे पता चला है कि यदि आप yarn add path/to/package.tgz स्थापित करते हैं और फिर संग्रह को किसी दूसरे से बदल देते हैं, तो आप नए संस्करण को बस yarn add path/to/../to/package.tgz , इसलिए पूर्ण पथ समान है, लेकिन यार्न के लिए यह अलग है ।

मुझे समझ में नहीं आ रहा है कि संकल्प पथ द्वारा यार्न स्टोर कैश्ड पैकेज कहां हैं, यहां तक ​​कि yarn cache list --pattern package खाली है।

मुझे लगता है कि समस्या यहीं कहीं है https://github.com/yarnpkg/yarn/blob/eb2b565bb9b948e87b11119482ebc184a9d66141/src/resolvers/exotics/tarball-resolver.js#L58 -L63

क्या हो रहा है:

• Url path/to/package.tgz हैश से उत्पन्न होता है (इसीलिए path/to/package.tgz और path/to/../to/package.tgz अलग-अलग हैश के परिणाम)
• उस हैश पैकेज के लिए अस्थायी निर्देशिका बनाता है (जैसे यह एक /Users/kich/Library/Caches/Yarn/v4/.tmp/c019816ee7d10ed5e1fef4072e8cc617 )
• पहले isValidModuleDest वापसी false चलें और सब सही हो जाए
• इस निर्देशिका में टारबॉल पैकेज निकाले गए
• उस निर्देशिका से फ़ाइलें प्रोजेक्ट में स्थापित की गई हैं
• आप प्रोजेक्ट स्रोतों को संशोधित करते हैं और पिछले एक ही नाम और स्थान के साथ नए पैकेज टारबॉल का निर्माण / पैक करते हैं
• और आप नए टारबॉल को स्थापित करने की कोशिश करते हैं, लेकिन उत्पन्न हैश पहले की तरह ही है और पहले रन के बाद अस्थायी निर्देशिका को मंजूरी नहीं दी गई थी
• तो इस समय में isValidModuleDest रिटर्न true
• और यार्न अपने पैकेज के पुराने संस्करण को स्थापित करें
• आप yarn cache clean package चलाते हैं, लेकिन अस्थायी निर्देशिका अछूती रहती है

@bestander क्या हम यहां केवल अस्थायी निर्देशिका निकाल सकते हैं https://github.com/yarnpkg/yarn/blob/master/src/config.js#L431 ?

एक ही समस्या का सामना करते हुए, मैं केवल एक दिन के लिए अपने स्थानीय pacakge पर काम करने के बाद अस्थायी फ़ोल्डर के तहत कैश 10GB लेता हूं!

क्या हम इस मुद्दे को फिर से खोल सकते हैं? हम उसी समस्या का सामना कर रहे हैं। फ़ाइल के माध्यम से दूसरे पैकेज को संदर्भित करने वाली दो परियोजनाएँ:। हमारे CI / CD सर्वर में कुछ बिल्ड के बाद, कैश फ़ोल्डर बहुत सी जगह पर कब्जा करना शुरू कर रहा है।

मुझे लगता है कि इसके लिए लिंक प्रोटोकॉल सबसे अच्छा फिक्स है, फ़ाइल: // काम नहीं करता है क्योंकि इसे अभी भी मैन्युअल रूप से साफ कैश और फोर्स इंस्टॉल करने की आवश्यकता है

https://github.com/yarnpkg/yarn/issues/2165#issuecomment -345825904

बस अपनी निर्भरता को कुछ इस तरह बनाओ

"<package>": "link:./libs/<package>"

@alxtz लिंक प्रोटोकॉल tgz में संकुल के साथ काम करता है?

मुझे लगता है कि इसके लिए लिंक प्रोटोकॉल सबसे अच्छा फिक्स है, फ़ाइल: // काम नहीं करता है क्योंकि इसे अभी भी मैन्युअल रूप से साफ कैश और फोर्स इंस्टॉल करने की आवश्यकता है

# 2165 (टिप्पणी)

बस अपनी निर्भरता को कुछ इस तरह बनाओ

"<package>": "link:./libs/<package>"

धन्यवाद इस के लिए इस NPM का व्यवहार जो सिमलिंक जाएगा replicates file:.. में संदर्भ node_modules । यह प्रलेखित नहीं दिखता है, कम से कम यहां नहीं जहां मैं इसे खोजने की उम्मीद करूंगा: https://yarnpkg.com/lang/en/docs/package-json/

अफसोस की बात है, सभी मामलों में link उपयोग नहीं किया जा सकता है।

उदाहरण के लिए, मुझे अपने एसडीके पैकेज से एक साझा / सहकर्मी निर्भरता की आवश्यकता है, जो जब मैं परिवर्तन करता हूं, तो मैं स्थानीय देव कार्य के लिए लिंक करूंगा।
link , यार्न को यह पता नहीं चलता है कि निर्भरता एक साझा / सहकर्मी निर्भरता है और स्थानीय पैकेज का उपयोग करता है जहां सिमिलिंक है, जो गलत है।

मैं yarn pack का उपयोग कर रहा हूँ yarn add file:<path_to_packed_tgz> आसपास पाने के लिए।
जब भी मैं पैकेज को हर बार पैक करने के लिए जारी रख सकता हूं और इसे अपने रेपो में पेस्ट कर सकता हूं, इसलिए @wKich शानदार खोज के अनुसार, समान हैश उत्पन्न करने के लिए नहीं, यह बहुत कष्टप्रद है।

मैंने रेपो को forked किया और अगर स्टेटमेंट में यार्न को रोकने के लिए एक अतिरिक्त क्लॉज लगा दिया तो उसके कैश से एक स्थानीय .tgz पैकेज लोड करने से अगर यह yarn add file:<path> का उपयोग करके निर्दिष्ट किया गया है।

const dest = this.config.getTemp(crypto.hash(url));
// If specified using file: never load from cache
if (!url.match(/file:/) && (await this.config.isValidModuleDest(dest))) {
  // load from local cache
} else {
  // continue as if it's a new package
}

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

@ojboj अभी के लिए, yalc मदद कर सकता है जब तक कि यह एक उचित फिक्स नहीं हो जाता। यह मेरे लिए काम कर रहा है वास्तव में प्रकाशन से पहले संकुल का परीक्षण करने के लिए।

@soupors रहस्यमय यह वही है जो मुझे चाहिए था / चाहता था, बहुत बहुत धन्यवाद!

इतने सालों बाद भी यह एक मुद्दा है।

क्या यह यार्न@2.x में तय है

@ मैं ऐसा मानता हूँ! मैंने व्यक्तिगत रूप से इसका परीक्षण नहीं किया है, लेकिन ऐसा लगता है कि वे नए पोर्टल प्रोटोकॉल के माध्यम से स्थानीय विकास को हल करते हैं।

मुझे अभी भी link: प्रोटोकॉल का उपयोग करके "एक ही गंतव्य में" त्रुटि मिलती है, और यह मेरे कैश डीआईआर का संदर्भ दे रहा है, इसलिए ऐसा लगता है कि यार्न अभी भी link: निर्भरता को कैशिंग कर रहा है। मैं उसी स्थानीय पैकेज की 2 प्रतियों का उल्लेख कर रहा हूं, जो प्रत्येक एप्लिकेशन के .deps/ फ़ोल्डर में प्रतिलिपि बनाई गई है - जो front-end और renderer नीचे त्रुटि में है। (असंबंधित कारणों के लिए मूल से लिंक नहीं किया जा सकता)

warning Pattern ["@horizon/common<strong i="11">@link</strong>:packages/front-end/.deps/@horizon/common"] is trying to unpack in the same destination "/home/garyo/.cache/yarn/v6/[email protected]/node_modules/@horizon/common" as pattern ["@horizon/common<strong i="12">@link</strong>:packages/renderer/.deps/@horizon/common"]. This could result in non-deterministic behavior, skipping.