Yarn: पैकेज को बचाने के बिना पैकेज जोड़ें। json

नहीं, यह फीचर जानबूझकर छोड़ा गया था। पैकेज में प्रतिबिंबित किए बिना पैकेज को स्थापित करना खतरनाक माना जाता है। आप ऐसी चीज़ क्यों चाहते हैं?

फेसबुक की घोषणा से

हमने npm स्थापित के "अदृश्य निर्भरता" व्यवहार को हटा दियाऔर कमांड को विभाजित करें। yarn add <name> चलाना npm install --save <name> चलाने के बराबर है।

मैं इस्तेमाल किया है कि सुविधा का उपयोग अक्सर चीजों का परीक्षण करने के लिए। खासकर जब मैं एक पुस्तकालय के साथ काम कर रहा हूं जिसे मैं बनाए रखता हूं और एक स्थानीय संस्करण (जो file: dep बनाता है) को स्थापित करने की आवश्यकता है, तो रिलीज से पहले मेरे परिवर्तनों का परीक्षण करें।

जबकि मैं सहमत हूं कि एनपीएम के कार्यान्वयन को डिफ़ॉल्ट रूप से करना एक खराब विकल्प था, मुझे लगता है कि यह कुछ ऐसा है जो स्पष्ट रूप से उपयोग किए जाने पर काम में आ सकता है।

हाँ, मुझे लगता है कि इसे स्पष्ट ध्वज के साथ करने की अनुमति देना अच्छा होगा, वर्तमान में इसके लिए अभी भी npm i = का उपयोग किया जा सकता है) लेकिन सिर्फ npm की जरूरत से छुटकारा पाने के लिए।

हम स्पष्ट रूप से इसका समर्थन नहीं करते क्योंकि यह node_module के लिए एक अनिवार्य परिवर्तन है जिसे बाद में yarn install s से मिटा दिया जाएगा क्योंकि हम package.json और yarn.lock होना मानते हैं। सत्य का स्रोत।

हमारी एक निर्भरता है जो आसानी से विंडोज़ पर स्थापित नहीं की जा सकती है (libxslt)

• विंडोज़ के लिए: डेवलपर्स इसे अपने नोड_मॉड्यूस में खोल देते हैं
• Linux के लिए: डेवलपर्स इसे बिना सेव के इंस्टॉल करते हैं (अगर यह पैकेज में है। तो विंडो का उपयोग करने वाले डेवलपर्स कोई भी इंस्टॉल नहीं कर सकते क्योंकि बिल्ड विफल हो जाएगा)

क्या यार्न का उपयोग करने का एक साफ तरीका है (या इस परिणाम को प्राप्त करने का कोई बेहतर तरीका)?

(मैं आपसे सहमत हूं कि पैकेज पैकेज में परिलक्षित होना चाहिए। हालांकि, यहां पर मुझे कोई साफ समाधान नहीं मिल सकता है)

@GuillaumeLeclerc yarn add -D xxx बारे में क्या है और पैकेज से प्रविष्टि को हटा दें?

अगली बार एक और पैकेज जोड़े जाने पर इसे हटा दिया जाएगा? नहीं होगा?

@GuillaumeLeclerc दुर्भाग्य से, हाँ।

@GuillaumeLeclerc आप अपनी टिप्पणी को साफ करना चाहते हो सकता है ...

कृपया yarn add --no-save जैसे एक तर्क जोड़ें, ताकि मैं अपने पैकेज में बदलाव किए बिना एक मॉड्यूल स्थापित कर सकूं। json या यार्न ।लॉक। मैं अक्सर अपने आप को उनके लिए प्रतिबद्ध करने से पहले मॉड्यूल का परीक्षण करने की आवश्यकता पाता हूं।

मैं सामान्य npm install उपयोग नहीं कर सकता क्योंकि मुझे "अधिकतम कॉल स्टैक आकार पार हो गया है"। तो यार्न स्थापित करने का एकमात्र व्यवहार्य तरीका है।

कृपया मुझे package.json यार्न के लिए परिवर्तन वापस न करें।

मेरे लिए, यह मुझे काट रहा है क्योंकि मैं एक peerDep स्थापित करने की कोशिश कर रहा हूं। यार्न के पास install दौरान सहकर्मी डिपो स्थापित करने का कोई तरीका नहीं है, इसलिए मुझे मैन्युअल रूप से करना होगा। मैं yarn add <package> बिना इसे पैकेज में जोड़े हुए नहीं पा सकता हूँ। मैं फँस गया हूँ।

@viveleroi यह पूरी तरह से सही लगता है। आप अपने package.json जोड़े बिना सहकर्मी निर्भरता को क्यों स्थापित करना चाहेंगे?

@hpurmann क्योंकि यह मेरे peerDependencies को dependencies (या devDependencies डुप्लिकेट करता है अगर मैं --dev उपयोग करता हूं)। अगर यही इरादा है तो यह निश्चित रूप से सहज नहीं है।

@ हूपमैन मैं एक प्रतिक्रिया घटक को सार्वजनिक करना चाहता हूं, इसलिए प्रतिक्रिया एक सहकर्मी होना चाहिए। हालांकि, मुझे इसे विकसित करने के लिए परियोजना में प्रतिक्रिया स्थापित करने की आवश्यकता है।

बस जोड़ें - नहीं-सहेजें => यह इतना महत्वपूर्ण है
मुझे विशिष्ट पैकेज के लिए एक विशेष वैकल्पिक निर्भरता को छोड़ना होगा। मैं अपने सूत के साथ ऐसा नहीं कर सकता। के साथ हो सकता है - नहीं-बचा विकल्प मैं इसे घेरने का काम कर सकता हूं

क्योंकि yarn link local-pkg होस्ट ऐप में स्थानीय-pkg की निर्भरता को स्थापित नहीं करता है, मैं उन्हें सीधे इंस्टॉल करना चाहूंगा लेकिन उन्हें ऐप पैकेज में नहीं सहेजूंगा। प्रकाशित होने के बाद उन्हें स्थानीय-pkg द्वारा लाया जाएगा। ।

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

मैं यार्न को NWSJS प्रोजेक्ट के लिए उपयोग करने की कोशिश कर रहा हूं जो AWS लैम्ब्डा पर चलाया जाता है। मुझे आश्चर्य है कि यह सुविधा समर्थित क्यों नहीं है। मेरा उपयोग मामला यह है कि मुझे अपने स्थानीय देव वातावरण पर aws-sdk स्थापित करने की आवश्यकता है, लेकिन मैं नहीं चाहता कि इसे package.json में बचाया जाए क्योंकि AWS लैंबडा में पहले से ही यह उनके पर्यावरण पर स्थापित है। Aws-sdk को शामिल करने का मतलब है कि हमारा अंतिम पैकेज फूला हुआ होगा।

यार्न लिंक और यार्न ऐड एक साथ नहीं रह सकते हैं। यार्न ऐड पैकेज.जसन पर निर्भर करता है जबकि यार्न लिंक सिर्फ स्थानीय पैकेज को किसी अन्य स्थान से जोड़ता है।

मान लीजिए कि आप एक पैकेज X विकसित कर रहे हैं जो Y पर निर्भर करता है, आप X और Y दोनों के डेवलपर हैं, इसलिए आप X और Y को स्थानीय रूप से रखते हैं और Y को X की निर्देशिका में लिंक करते हैं। जब आप X में यार्न जोड़ते हैं, तो यह समाप्त हो जाता है Y का लिंक।

आप इसके आसपास कैसे पहुंचते हैं?

~ ऐसे मामलों के लिए आप पैकेज json या यार्न पर एक पदचिह्न बनाए बिना स्थापित करने के लिए बस npm-कमांड का उपयोग कर सकते हैं।

~ npm install [packages ...] --no-save --no-package-lock ~

जैसा कि @heikomat ने कहा है, चूंकि npm5 इंस्टॉल के बाद ऑटो-प्रून का उपयोग करता है (देखें https://github.com/npm/npm/issues/16853 + https://github.com/npm/npm/pull/18921) एक विकल्प नहीं है और आपके नोड_मॉडल-फ़ोल्डर को पूरी तरह से तोड़ सकता है।

ठीक है तो अब मैं npm के बिना नहीं रह सकता

मैं अपनी एक स्क्रिप्ट में npm install का उपयोग कर रहा था जो स्थानीय उप-मॉड्यूल की निर्भरता को मुख्य नोड_बोड्यूल्स पर स्थापित करता है। यह npm4 के साथ ठीक काम कर रहा है, लेकिन npm5 के साथ पूरी तरह से टूट गया है, क्योंकि npm5 सिर्फ install-दौरान कुछ संकुल को nuke तय करता है ।- (देखें https://github.com/npm/npm/pull/18921)

उस कारण से, मैं अपनी स्क्रिप्ट में npm install को यार्न से बदलने का प्रयास कर रहा था, लेकिन मैं वास्तव में ऐसा नहीं कर सकता, यदि यार्न हमेशा पैकेज को छूता है। स्थापना के दौरान स्थानीय सबमॉडल्स के जोंस, कम से कम बिना मेरी स्क्रिप्ट शांत गड़बड़ हो रही है और यार्न के बाद "सफाई" कर रही है

आपके पास पहले से ही --no-lockfile विकल्प है, इसलिए यह नोड_मॉडल फ़ोल्डर को सोच से बाहर कर देता है,
लेकिन देवों को पैकेज रखने के लिए वर्कअराउंड की जरूरत है।

धन्यवाद।

मुझे पसंद है कि हर बार जब कोई किसी मॉड्यूल को स्थापित करने के लिए अपने अजीबोगरीब उपयोग के मामले की व्याख्या करता है, लेकिन इसे रिकॉर्ड नहीं करता है तो अनुरक्षक वापस आते हैं और अपने शिबोलेथ का पाठ करते हैं। यदि आप एक नैतिक असफलता से पीड़ित लोगों से आ रहे हैं, तो कई अलग-अलग लोगों से इस अनुरोध को काउच कर सकते हैं, अगर आपको अपने संयम पर विश्वास करना आसान बनाना चाहिए। एक समझौते के रूप में, शायद हम स्विच --i-am-a-heritic-and-a-bad-programmer नाम दे सकते हैं?

एक महत्वपूर्ण दोष को देखने के लिए yarn npm से बचता है

और मेरे मामले में मैं इसे # 4297 अंक के लिए समाधान के रूप में उपयोग करना चाहता था :)
चीजों को करने के लिए कृत्रिम रूप से डेवलपर्स को सीमित करना आपके उत्पाद को कुछ स्थितियों में बेकार कर सकता है।

रुको क्या तुम मुझसे मजाक कर रहे हो? यह एक देशद्रोही है। कृपया तय करना बंद करें कि हर डेवलपर वर्कफ़्लो को कैसे काम करना चाहिए, कभी भी। यही कारण है कि NPM ने हमें सूट नहीं किया और हम यार्न में चले गए। यह विचारधारा कि "package.json और यार्न .lock को सत्य का स्रोत होना चाहिए" निरर्थक है। स्रोत कोड को संशोधित किए बिना संकुल को स्थापित किया जाना चाहिए। इतना ही आसान।

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

अब मुझे लगता है कि yarn ने मेरे परीक्षण तोड़ दिए क्योंकि मेरे पास ऐसे मॉड्यूल हैं जहां मुझे require का परीक्षण करने की आवश्यकता है और परीक्षण करने के लिए मुझे ./node_modules में एक उदाहरण मॉड्यूल की आवश्यकता है। यार्न जब मैं yarn install चलाता हूं तो उदाहरण मॉड्यूल हटा रहा है। अधिक "सच्चाई का स्रोत" पैदल सेना, मुझे लगता है।

उपयोग का मामला: मेरे द्वारा उपयोग किए जाने वाले उपकरण के लिए पैकेज की आवश्यकता होती है। टीम उस टूल का उपयोग नहीं करती है। टीम (उचित रूप से) वह पैकेज स्थापित नहीं करना चाहती है।

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

यह 2018 पहले से ही है, लेकिन कई वैध उपयोग मामलों के बावजूद यह सुविधा अभी तक जोड़ी नहीं गई है।

सिर्फ एक और उदाहरण देना कि यह क्यों उपयोगी हो सकता है:

हमारे पास एक स्क्रिप्ट है जो नए संस्करण को स्थापित करके, परीक्षणों को चलाकर और package.json / *.lock सहेजकर निर्भरता को स्वचालित रूप से अपडेट करती है और यदि कोई त्रुटि हुई थी, तो उस परिवर्तन को वापस लाती है या वापस लेती है। पुराने संस्करण को याद करने के बजाय yarn फिर से चलाना आसान है और स्पष्ट रूप से adding फिर से।

इसके अलावा यह "बिल्कुल" होने से पहले अपने एकल बिंदु ( package.json ) को सच नहीं करने के लिए क्लीनर महसूस करता है यह सुनिश्चित करने के लिए कि आप वास्तव में एक परीक्षण को तोड़ने के बिना इस निर्भरता को अपडेट करने में सक्षम हैं। अभी के लिए आप एक package.json (भले ही यह अस्थायी रूप से हो) के साथ समाप्त होते हैं जिसमें एक निर्भरता होती है जो आपके कोड को तोड़ती है।

इस समस्या के लिए कई मान्य उपयोग-मामले हैं। यदि किसी को बनाया जाना था, तो क्या यार्न के लिए बनाए जाने वाले प्रोटोपैक पीआर को स्वीकार करने के लिए तैयार होंगे?

pinging @kittens यदि आप अभी भी इस परियोजना से जुड़े हैं ...

इस बीच, मैं scripts अनुभाग package.json में निम्नलिखित स्क्रिप्ट का उपयोग करता हूं:

"scripts": {
  "install-sneaky-package": "npm install -g sneaky-package && cp -r $(npm root -g)/sneaky-package ./node_modules/sneaky-package"
}

मुझे लगता है कि यार्न के लिए एक विकल्प है?

कोई विकल्प नहीं है, npm5 मेरे जीवन के रूप में गड़बड़ है।

और .bin फ़ोल्डर में सिमलाइन को कॉपी करना न भूलें। ;)

मेरे लिए chmod 444 package.json और yarn add XXXX --no-lockfile कम से कम स्थानीय विकास और परीक्षण के मुद्दे के आसपास काम करता है।
ऐड एक (अपेक्षित) अनुमति त्रुटि के साथ समाप्त होता है, लेकिन जोड़ा मॉड्यूल बाद में नोड_मॉड्यूल्स में मौजूद है और मैं स्थानीय रूप से स्थापित सहकर्मी निर्भरता के साथ परीक्षण करने में सक्षम हूं, लेकिन पैकेज में जारी नहीं है। लेकिन पीयर निर्भरता के रूप में।

मुझे कभी-कभी अस्थायी रूप से डिबगिंग लाइब्रेरी की आवश्यकता होती है, जैसे why-is-node-running । मुझे पता है कि मैं एक एकल उपयोग के बाद इससे छुटकारा पाना चाहता हूं, और एक --no-save विकल्प मुझे मेरी निर्भरता को प्रदूषित करने के जोखिम को चलाने के बिना, स्थापित करने और भूलने की अनुमति देगा।

मैं Lerna का उपयोग कर रहा हूं, और मैं वास्तव में अपने CI चरणों में से एक में _only_ Lerna को प्रकाशित चरण के लिए स्थापित करना चाहता हूं, क्योंकि परियोजना पहले से ही एक पिछले चरण में बनी है और कलाकृतियां बनाई गई हैं। क्या यह एक वैध परिदृश्य है?

यह मुझे कुछ चरणों को बचाएगा, अगर यह सुविधा उपलब्ध होगी।
मेरा node_modules । वैसे भी .ignignore में है।

के बजाय:

git clone external-package (needed for temp testing only)
yarn install
yarn link

मेरे मूल रेपो पर वापस जाएं
yarn link external-package

बस:
मूल-रेपो:
yarn install external-package --no-save

हमारी बिल्ड पाइपलाइनों के हिस्से के रूप में, हमें nsp स्थापित करने और इसे चलाने की आवश्यकता है, जो एक निर्भरता-चेक.xml निर्यात करता है।

मैं यह नहीं देखता कि इस सरल टूल इंस्टॉल को पैकेज सूची में परिलक्षित होने की आवश्यकता क्यों है, इसका मतलब यह है कि अब मुझे टैग्स को पुश करने से पहले संशोधनों को पूर्ववत करने के लिए git checkout ${BRANCH_NAME} करने की आवश्यकता है।

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

किसी भी विचार, क्यों इस मुद्दे को बंद कर दिया गया है? क्या PR में --no-save स्विच जोड़ा गया है?

कई बार मैं एक मॉड्यूल के संस्करण को बदलना चाहता हूं जो एक निर्भरता से लाया जाता है। उदाहरण के लिए, एक और देव निर्भरता द्वारा लाया गया @types/sinon ने हाल ही में मेरा tsc तोड़ दिया। मैं अपने देव निर्भरता के लिए @types/sinon नहीं चाहता, लेकिन मैं मैन्युअल रूप से yarn add @types/[email protected] --no-save साथ संस्करण बदलना चाहता हूं ताकि मैं काम कर रख सकूं। इसके बजाय, मैं सिर्फ npm पर वापस जाता हूं। सुपर निराशा होती है।

मेरे पास केवल निर्भरता (एपीडायनामिक्स) का एक उत्पादन है जो बहुत ही मंच-विशिष्ट बायनेरिज़ का एक हैक है। पता चलता है कि हम भी देव मशीनों पर इसकी जरूरत नहीं है। yarn add ... --no-save जोड़ने से हम पैकेज को खतरे में डालने वाली स्क्रिप्ट के बिना साफ-सुथरे ढंग से तैनात हो सकते हैं।

cc @kittens @hpurmann

कृपया या तो इस अविश्वसनीय रूप से लोकप्रिय मुद्दे को संबोधित करें या इसे हल करें। उपरोक्त सभी आलोचनाओं के जवाब में ठोस जवाब देने के लिए इसकी बहुत सराहना की जाएगी।

और समुदाय सुविधा प्रदान करने के लिए तैयार है, बस हमें बताएं कि क्या आप ऐसे पुल अनुरोध स्वीकार करेंगे। धन्यवाद।

haha, अभी भी लागू नहीं किया गया है, niiiiice

आप ऐसी चीज़ क्यों चाहते हैं?

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

@ किटनेंस
मेरे पास प्रतिक्रिया के आधार पर कई पैकेज हैं और इनमें एक दूसरे पर उप-मॉड्यूल निर्भरताएं हैं। इसलिए मेरे पास सहकर्मी के रूप में प्रतिक्रिया और प्रतिक्रिया-डोम है लेकिन जब मुझे इन पैकेजों को व्यक्तिगत रूप से बनाने की आवश्यकता होती है तो मुझे प्रतिक्रिया और प्रतिक्रिया-डोम की आवश्यकता होती है।
मुझे लगता है कि यह स्थानीय रूप से पैकेजों को स्थापित करने के लिए एक उपयुक्त उपयोग-मामला होगा, उन्हें डिप के रूप में जोड़े बिना।
मैं अपनी परियोजना में इस तरह के एक तुच्छ उपयोग के लिए npm नहीं लेना चाहूंगा।
किसी भी अद्यतन, --no-save समान कुछ के लिए प्रतीक्षा कर रहा है।
मुझे लगता है कि कोई सुविधा जोड़ने से कोई नुकसान नहीं है अगर समुदाय मांग करता है, तो यह मानकर कि इसके दुष्प्रभावों के बारे में पता है (जैसे ही आप यार्न स्थापित चलाते हैं, स्थानीय पैकेज खो देते हैं।)
धन्यवाद

हैंडी ट्रिक yarn add --dev pkg && yarn remove pkg । यह वही काम करता है। इससे पहले कि वह इससे अछूता था, लॉक लॉकाइल रहता है।

यह @Legends द्वारा पहले उल्लेख किया गया था लेकिन जोर देने लायक है:

कुछ मामलों के लिए एक वर्कअराउंड आवश्यक पैकेज को एक अलग फ़ोल्डर में स्थापित करना है और yarn link आवश्यक पैकेज को जहाँ कहीं भी जोड़ा गया है, वहाँ स्थापित करना है। यह आदर्श नहीं है लेकिन मदद कर सकता है।

cd /third-party
yarn add foo
cd node_modules/foo
yarn link

cd /my-project
yarn link foo

@silentorb निश्चित रूप से लायक नहीं है, imho। add + remove बिल्कुल वही है जो --no-save साथ npm में किया जाता है। यह सिस्टम लिंक के साथ गड़बड़ नहीं करता है और लॉकफ़ाइल को खराब तरीके से नहीं छू रहा है - मतलब yarn remove बाद भी ऐसा ही है।
यह उल्लेख नहीं करने के लिए कि यदि आप उस चीज़ को प्रोग्रामेटिक रूप से करना चाहते हैं, तो निश्चित रूप से डायर, लिंकिंग और आदि बनाना नहीं है।

कुछ मामले

उदाहरण के लिए? सुंदर अजीब यकीन के लिए?

@ हहम्मन @ कटिटेंस

तो सहकर्मी निर्भरता के साथ एक पैकेज विकसित करने के लिए अनुशंसित अभ्यास क्या है?

अगर मेरे पास मेरे पैकेज में सहअस्तित्व के रूप में अभिक्रिया है, तो क्या मुझे आयात को हल करने के लिए इसे एक निर्भरता के रूप में जोड़ना चाहिए?

Https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/package.json को देखते हुए मुझे लगता है कि उत्तर हां है

@ 18steps https://www.npmjs.com/install-peers देखें

इस सुविधा का उपयोग करने के लिए कुछ स्थितियां हैं।

जैसे सीआई जीवन चक्र में मैंने कुछ कवरेज रिपोर्टर जोड़े। लेकिन मैं उन्हें package.json नहीं ला सकता, फिर NPM प्रकाशित करने के लिए प्रभावित करता है।

सहेजें या न बचाएं, मुझे लगता है कि यह विकल्प डेवलपर्स के पास होना चाहिए न कि उपकरण के लिए।

ठीक है, चलो इसे बनाए रखने के दृष्टिकोण से देखने की कोशिश करते हैं। मैं निश्चित रूप से एक --no-save समाधान के लिए नीचे देख सकता हूं। हमें यहां बहुत गहन व्याख्या नहीं मिली, लेकिन मैं एक स्टील मैन बनाने की कोशिश करूंगा। शायद वे मुझे सही कर सकते हैं। शायद हम एक समझौता पा सकते हैं। @ किटनेंस

(क्षमा करें, यह मेरी अपेक्षा से अधिक समय तक समाप्त हो गया।)

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

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

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

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

हालाँकि , मैं समझौता करने के कई कारण देख सकता हूँ:

• लगता है यहाँ एक निश्चित जरूरत है। उपरोक्त टिप्पणियों में सूचीबद्ध कई उपयोग-मामलों को देखें, और 'अंगूठे ऊपर' / 'नीचे अंगूठे' अनुपात। इस तरह की एकतरफा प्रतिक्रिया के सामने दर्शकों की स्पष्ट जिद यार्न को बहुत अच्छा नहीं बनाती है।

• ऐसे समाधान पाए जा सकते हैं जो सभी के लिए काम कर सकते हैं। उदाहरण के लिए, एक नई फ़ाइल yarn.local.lock । डेवलपर्स इसे अपने .gitignore , और यह --no-save ध्वज और उनकी निर्भरता के साथ स्थापित सभी पैकेजों का रिकॉर्ड रखेगा।

  yarn.lock अलग रखने के लिए, 'स्थानीय' निर्भरता के पेड़ का कटाव और सपाट होना प्रतिबंधित है। स्थानीय लॉक फ़ाइल मुख्य लॉक फ़ाइल में एक संस्करण से मेल खाने के लिए अनुकूल हो सकती है (और उस मामले में कटौती) लेकिन आसपास के अन्य तरीके से नहीं। परिणामस्वरूप, कई सकर्मक स्थानीय निर्भरता node_modules में समतल नहीं हो सकती है।

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

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

मुझे कुछ याद आ गया होगा, लेकिन यह एक बातचीत के लायक लगता है।

मेरे पास एक और उपयोग मामला है: मैं REPL में उपलब्ध होने के लिए एक मॉड्यूल चाहूंगा, लेकिन इसे अपने कोड में उपयोग करने का इरादा नहीं है। जैसा कि यह खड़ा है मुझे एक अलग फ़ोल्डर में जाने और वहां उस मॉड्यूल को स्थापित करने की आवश्यकता है, फिर ../other-project/data/xyz.json का उपयोग करके कुछ json फ़ाइलों को आयात करें।

लेकिन अगर मैं एक मॉड्यूल आयात करना चाहता हूं और वह चीज अन्य रास्तों का उपयोग करके रिश्तेदार पथों का आयात करता है, तो ठीक है, यह टूटने वाला है।

बस मुझे बचत के बिना node_modules में एक मॉड्यूल स्थापित करने की अनुमति देता है यह सब बहुत आसान बना देगा।

मुझे आश्चर्य है कि अनुचर इस विचार के प्रति कितने प्रतिरोधी हैं।

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

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

एकमात्र समाधान जो मैंने पाया है वह peerDepencies devDependencies रूप में स्थापित कर रहा है जो बिल्कुल भी आदर्श नहीं लगता है, लेकिन यह समस्या के आसपास काम करता है। अपनी भयानक स्थिति में कम से कम npm आपकी package.json फ़ाइल को संशोधित किए बिना स्थापित करता है।

@ हहम्मन

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

मुझे शायद कुछ समय पहले जवाब देना चाहिए था, ठीक इसके बाद @viveleroi ने अपने काफी वैध उपयोग के मामले (जो आप में से बहुत से लगते हैं) को समझाया। इसके बाद मैंने उनकी प्रतिक्रिया पर अंगूठा लगाया, जो स्पष्ट रूप से उल्लेखनीय नहीं है।

मैंने अपना मन बदल लिया है। आमतौर पर, लोग बहुत सी चीजें चाहते हैं और अगर रखवाले हर सुविधा को स्वीकार कर रहे हैं, तो सॉफ्टवेयर फूला हुआ हो जाता है। मेरे पास यह उपयोग मामला नहीं है, लेकिन मैं कई लोगों को यह देखना चाहता हूं।

मैं हालांकि कुछ भी तय नहीं कर सकता। मैं इस परियोजना का अनुरक्षक नहीं हूं।

@Vheissu yarn add --peer <dep> साथ क्या समस्या है?

मेरे लिए यार्न ऐड - वेपरकाम करता है UNTIL आप एक और पैकेज जोड़ते हैं, जिस बिंदु पर मौजूदा पीयर डिप को स्थानीय इंस्टॉल से हटा दिया जाता है और आपको उन्हें मैन्युअल रूप से पढ़ना होता है।

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

@ ब्रेंडन-हर्ले @suyanhanx की तरह , मेरी निर्भरता है कि मैं सीआई में स्थापित करना चाहता हूं और स्थानीय रूप से नहीं।
मैं अपनी स्थानीय निर्भरता को कम से कम रखना चाहता हूं ताकि हमें node_modules फूंकने की जरूरत न पड़े और प्रोजेक्ट पर काम करने वाले हर डेवलपर के लिए हमें समय और स्थान खर्च करना पड़े।

पैकेज जो CI में आवश्यक हैं, लेकिन स्थानीय स्तर पर नहीं:

• CI विशिष्ट उपकरण: सिमेंटिक-रिलीज़, ग्रीनकीपर-लॉकफ़ाइल
• कवरेज रिपोर्टिंग उपकरण: कोडेसी-कवरेज, कवरॉल
• सीआई के लिए टेस्ट रिपोर्टिंग टूल: जेस्ट-जूनिट, आदि।

यहाँ हमें इस सुविधा की आवश्यकता है:

yarn link अभ्यस्त का उपयोग पैकेज की निर्भरता को जोड़ता है, इसलिए आपको उन्हें स्थापित करने की आवश्यकता है
लिंक की गई मंजिल - ये बाहरी निर्भरता package.json बस इतना असुविधाजनक हो जाता है।

या तो yarn link को निर्भरता जोड़ना है या गंतव्य package.json में गंतव्य को बाहर करने का एक तरीका प्रदान करना है

मेरे पास एक बहुत गूढ़ उपयोग मामला है, लेकिन यह मेरे लिए उपयोगी होगा। मैं पूरी तरह से समझता हूं कि yarn.lock और package.json सच्चाई का स्रोत होने के लिए महत्वपूर्ण है, और यह कि अगर मैंने --no-save आदेश का उपयोग किया, तो मेरे परिवर्तन बाद के yarn पर मिटा दिए जाएंगे

उस ने कहा, मेरी इच्छा है कि yarn मुझे यह जानने में विश्वास हो कि मैं क्या कर रहा हूं और मुझे --no-save झंडा पास करने की अनुमति देगा। यदि मैं किसी भी समस्या के मामले में भाग लेता हूं, तो मुझे पता चल जाएगा कि क्या गलत हुआ, और यह कि मुझे केवल खुद को दोषी ठहराना है। :मुस्कुराओ:

मेरा उपयोग मामला?
मैं 64-बिट जीतने वाली मशीन चलाता हूं।
उत्पादन मशीन 32-बिट है।

जब तक हम पैकेज को अपडेट नहीं करते हैं, तब तक नोड-एसएएस निर्भरता हमारे पास केवल 32-बिट का समर्थन करती है।

एक देव मशीन का समर्थन करने के लिए Package.json या यार्न में निर्भरता को नहीं बदलना।
इसलिए स्थानीय स्तर पर 64-बिट का समर्थन करने के लिए नवीनतम नोड-एसएएस स्थापित करना चाहते हैं, लेकिन पैकेज को प्रभावित नहीं करते हैं। जसन और यार्न बैल

मैं VSCode में बेहतर स्वतः पूर्णता के लिए package.json / yarn.lock लाभ लिए बिना गैर-टाइपस्क्रिप्ट प्रोजेक्ट्स में @types/* पैकेज स्थापित करना चाहूंगा।

मैं यार्न के साथ कार्यक्षेत्र का उपयोग करता हूं।
Antd का प्रकार परिभाषा @ प्रकार / प्रतिक्रिया@16.8.12 अद्यतन के कारण टूट जाता है।
सप्ताहांत में Antd यह तय करेगा।
लेकिन अब मुझे यार्न को मजबूर करने की जरूरत है @ @ के एक निश्चित संस्करण को स्थापित करने के लिए / type @ रीट में मैन्युअल रूप से मौजूदा पैकेज को प्रभावित किए बिना।

Package.json को बचाने का डिफ़ॉल्ट व्यवहार सही है, लेकिन ऐसे वास्तविक मामले हैं जो डेवलपर को पैकेज को प्रभावित किए बिना मॉड्यूल को स्थापित करना चाहिए। विशेष रूप से तब जब कुछ पैकेजों में कुछ अप्रत्याशित परिवर्तन होते हैं।

कथित तौर पर पैकेज को अद्यतन करना और पैकेज को संक्षेप में सहेजना। जुझारू संघर्ष की ओर ले जाता है।

यहाँ एक और उपयोग मामला है। मैं एक रिएक्ट लाइब्रेरी बनाए रखता हूं। एक नया संस्करण प्रकाशित करने से पहले, मैं यह सत्यापित करना चाहता हूं कि react और react-dom कई संस्करणों के साथ, यह सत्यापित करने के लिए कि मेरे परिवर्तन पीछे और आगे ( @next ) संगत हैं। मैं नीचे सेटअप का उपयोग करके ऐसा कर रहा था, लेकिन अब मैं यार्न के कार्यक्षेत्रों का उपयोग करना चाहता हूं, इसलिए मुझे यार्न को स्थानांतरित करने की आवश्यकता है।

"test:backwards": "npm i [email protected] [email protected] --no-save && npm test",
"test:forwards": "npm i react<strong i="9">@next</strong> react-dom<strong i="10">@next</strong> --no-save && npm test",
"test:latest": "npm i react<strong i="11">@latest</strong> react-dom<strong i="12">@latest</strong> --no-save && npm test",
"test:compat": "npm run test:backwards && npm run test:forwards && npm run test:latest"

मैं इस स्क्रिप्ट को अपने package.json रूप में बदल नहीं सकता क्योंकि यह मेरे प्रकाशित आदेश ( pack publish ) को अस्थिर परिवर्तनों के कारण विफल कर देगा।

मैं अपने CI पाइपलाइन में अतिरिक्त पैकेज जोड़ना चाहता हूँ परीक्षण पैकेज के बिना प्रयोजनों के लिए। पैकेज फ़ाइल को छूने के लिए (संभवत: एक फ़ाइल माउंट हो सकती है)।
ये देव घटकों का हिस्सा नहीं हैं।
देव मशीनों पर विकास और परीक्षण के दौरान, उन्हें स्थापित नहीं किया जाएगा और निर्माण और निर्माण के दौरान उन्हें स्थापित नहीं किया जाएगा, वे परीक्षण के दौरान सीआई सर्वर पर केवल आवश्यक और स्वीकार्य हैं।

यह सिर्फ npm का उपयोग करके काम करता है, लेकिन यार्न को npm पर चित्रण को हटाने में सक्षम होना चाहिए।
यह बहुत अच्छी तरह से हमें केवल यार्न के बजाय केवल एनपीएम का उपयोग करने के लिए वापस ला सकता है।

इसके अलावा, यह सिर्फ यार्न के वादे को पूरी तरह से एनपीएम को बदलने में सक्षम होने के कारण टूट जाता है, क्योंकि यह सिर्फ वही नहीं कर सकता है जो एनपीएम कर सकता है।

इसके अलावा हाँ बिल्कुल इस सुविधा को कुछ ध्वज के पीछे छिपाएं क्योंकि यह सामान्य उपयोग का मामला नहीं होना चाहिए, लेकिन किनारे का उपयोग का मामला होना चाहिए।

क्या तुम मजाक कर रहे हो ? एक साधारण स्विच जोड़ने के लिए 3 साल?

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

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

क्या तुम मजाक कर रहे हो ? एक साधारण स्विच जोड़ने के लिए 3 साल?

@spanasik और @Ryuurock : कृपया उच्च गुणवत्ता वाले सॉफ़्टवेयर की चर्चा करते समय विनम्र

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

@NickHeiner यहां 10 तर्कों की स्क्रीन है। और मुख्य बात जो हताशा को बढ़ाती है, वह यह नहीं है कि निर्वाहक बनाए रखता है, लेकिन वे इसे अनदेखा कर रहे हैं, तर्कों का जवाब नहीं देते हैं, जब लोग "इस बात से असहमत होते हैं, तो सुविधा के लिए एक तर्क दें"। और जब लोग निराश होते हैं, तो बेशक वे अप्रिय टिप्पणी छोड़ देते हैं। कृपया उपयोगकर्ताओं पर पूरी बात को दोष न दें।

मैं मानता हूं कि यह बेहतर होगा यदि अनुरक्षक यहां चर्चा को संबोधित करेंगे। कई वर्षों में लोगों के व्यापक समूह से स्पष्ट रूप से रुचि है। तो शायद मेरा सुझाव है कि @spanasik और @Rurourock को बस "एक तर्क करना चाहिए" अनुचित है, क्योंकि यह संभवतः यहां सब कुछ की तरह अनदेखा किया जाएगा।

और जब लोग निराश होते हैं, तो बेशक वे अप्रिय टिप्पणी छोड़ देते हैं। कृपया उपयोगकर्ताओं पर पूरी बात को दोष न दें।

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

आगे बढ़ने के रचनात्मक तरीके:

1. अन्य चैनलों पर इस धागे पर अनुचर का ध्यान आकर्षित करें (शायद उन्होंने इसे अनदेखा कर दिया है) और उनसे कम से कम यहाँ तर्क स्वीकार करने के लिए कहें, भले ही वे सहमत न हों।
2. कांटा / प्रतिस्थापन यार्न और परियोजना को एक तरह से लोगों को खुश करने के साथ नियंत्रित करते हैं।

हैंडी ट्रिक yarn add --dev pkg && yarn remove pkg । यह वही काम करता है। इससे पहले कि वह इससे अछूता था, लॉक लॉकाइल रहता है।

परीक्षित - काम नहीं करता।

मेरा उपयोग मामला निम्नलिखित है:
कुछ पैकेजों में वैकल्पिक एडिंस होते हैं जो 'आवश्यकता' से भरे होते हैं। मैं इन ऐड-इन्स को डिडिपेंडेंसीज़ सेक्शन में जोड़ना नहीं चाहता हूँ, इसलिए मैं 'यार्न ऐड माय-ऐड-इन' करता हूँ और इसे मैन्युअल रूप से package.json फ़ाइल से निकाल देता हूँ। मेरी क्लाउड CI पाइपलाइन पर मैं 'npm i' का उपयोग करता हूं, उन्हें (परीक्षण के लिए) जोड़ता हूं। अपनी स्थानीय पाइपलाइन पर मैं npm का उपयोग नहीं करना चाहता क्योंकि यह एक अतिरिक्त लॉक फ़ाइल बनाता है। मेरा सबसे अच्छा विकल्प अब npm का उपयोग करना है और फिर उनकी लॉक फ़ाइल को हटाना है (सत्य के प्रकट होने वाले दूसरे संस्करण को निकालने के लिए)।

इसलिए सब कुछ पढ़ने के बाद मेरे सवाल का रखवाले हैं:

• आप इतने असंगत क्यों हैं?
• हर सुविधा के माध्यम से इस दर्शन को लागू क्यों नहीं किया?
  
  
  
  • वह है: यह तय करना कि हम सभी के लिए चीजें कैसे होनी चाहिए और सभी सुविधाओं से अन्य सभी विकल्पों को हटा दें। पाठ्यक्रम में रहना! अपने आप से सच्चे बने रहो!
  
  

निर्विवाद तथ्य यह है कि सभी अच्छे सॉफ़्टवेयर में कॉन्फ़िगरेशन सेटिंग्स होती हैं क्योंकि अच्छा सॉफ़्टवेयर उपयोगकर्ता को यह चुनने की अनुमति देगा कि उसकी स्थिति के लिए सबसे अच्छा क्या है । और हमेशा 'package.json' फाइल को छूने के लिए अच्छा अभ्यास है - लेकिन ऐसे किनारे के मामले मौजूद हैं जहां 'यार्न' सिर्फ इस दर्शन के कारण कार्य तक नहीं है।

मुझे वास्तव में यार्न पसंद है क्योंकि इसकी सरल और तेज है । यह वास्तव में दुर्भाग्यपूर्ण है कि अनुचर एक ऐसी लड़ाई लड़ रहे हैं जिसमें वे ढीले होना सुनिश्चित करते हैं - क्योंकि समुदाय चीजों को काम करने के लिए धीमी गति से विश्वसनीय एनपीएम पर वापस लौटने के लिए मजबूर होता है।

चलो तापमान को थोड़ा नीचे कर देते हैं। किसी को भी घृणित महसूस करने की आवश्यकता नहीं है
सॉफ्टवेयर का टुकड़ा वे मुफ्त में उपयोग करने की अनुमति देते हैं।

15 जनवरी, 2020 को बुध पर, 23:17 हाज़िम यामासाकी वुकेलिक <
सूचनाएं@github.com> ने लिखा:

मुझे घृणा महसूस होती है कि यार्न मुझे एक निश्चित तरीके से काम करता है। मुझे पसंद है
अपने दम पर चीजों को तय करें, और मुझे यह पसंद नहीं है जब मेरे उपकरण मुझे बताते हैं कि मैं कैसे हूं
काम करना चाहिए, मेरी खुफिया समस्याओं का कम से कम और
अभी तक सबसे बड़ा किया जा रहा चीजों को प्राप्त करने में सक्षम नहीं है।

सही नियमों में विश्वास करना और यह कि कभी भी कोई अवसर नहीं होगा
उन्हें तोड़ देना भोला है। "सर्वोत्तम प्रथाओं" और के बीच अंतर है
"करो या मरो"। ओलिवर वेंडेल होम्स सीनियर के रूप में:

जवान आदमी नियमों को जानता है, लेकिन बूढ़ा आदमी अपवादों को जानता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAGKTAZSB4FNAIFLZIL547LQ6ACZNANCNFSM4CVUKFMA
।

अपने खुद के पैकेज मैनेजर बनाओ, कोई भी आप कुछ भी नहीं कर रहा है।

अपने तर्क में त्रुटि को इंगित करते हुए, बिल्कुल भी क्रोधित न हों:

यार्न मुझे एक निश्चित तरीके से काम करता है।

यार्न आपको कुछ नहीं कर रहा है, उन्होंने एक उपकरण बनाया है (मुफ्त में) और यह एक निश्चित तरीके से काम करता है। यदि आपको यह पसंद नहीं है तो इसका उपयोग कुछ और करें।

@foxbunny मैं आपकी घृणा को स्पष्ट करने की सराहना

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

@whitecolor टीम को एक अंक मिला है। वह विकल्प है - दास बेवकूफ है। यार्न गारंटियां नोड_मॉडल्स, पैकेज.जॉन और लॉक फ़ाइल के बीच संतुलन बनाती हैं और यह बहुत अच्छा है। यह सुरक्षित है .... npm --save खतरनाक है। इसने मुझे कई बार नीचा दिखाया

कृपया इसे रोकें

या कैसे सभी के बारे में बस उस उपकरण का उपयोग करें जो उनके सोचने के तरीके को बेहतर और शांत करता है।

मेरा उपयोग मामला है

मैं हमारे ऐप की उप-निर्भरता को अपडेट करना चाहता हूं
मैं इस निर्भरता को yarn link जोड़ता हूं
मैं तब हमारे ऐप में लिंक किए गए एक का उपयोग करता हूं
मैं हमारी लाइब्रेरी में कुछ निर्भरता जोड़ता हूं
yarn install (wtf नंबर 1) के बाद मुख्य एप्लिकेशन में जोड़ा गया निर्भरता निर्भरता नहीं है
फिर मुझे लगता है, ठीक है, चलो बस इसे ऐप में सहेजे बिना जल्दी से जोड़ दें ताकि मैं जांच कर सकूं कि क्या सामान काम करता है इससे पहले कि हम अपने काम के लिए अपडेट प्रकाशित करें
लेकिन - नहीं।

धन्यवाद

लेखकों द्वारा अनदेखा किए गए समुदाय को देखने के लिए क्षमा करें।

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

Tue, Mar 3, 2020 को 03:53 बजे Artur Kwiatkowski नोटिफिकेशन @github.com
लिखा था:

लेखकों द्वारा अनदेखा किए गए समुदाय को देखने के लिए क्षमा करें।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAGKTA7WL4R3R47HBU6EPI3RFTVTLANCNFSM4CVUKFMA
।

मैं Lerna का उपयोग कर रहा हूं, और मैं वास्तव में अपने CI चरणों में से एक में _only_ Lerna को प्रकाशित चरण के लिए स्थापित करना चाहता हूं, क्योंकि परियोजना पहले से ही एक पिछले चरण में बनी है और कलाकृतियां बनाई गई हैं। क्या यह एक वैध परिदृश्य है?

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

मैं यहाँ के रखवालों से सहमत होना चाह रहा हूँ:

1. मैं अपने तर्क से असंबद्ध हूं। मुझे लगता है कि इसे मूर्खतापूर्ण तर्क होने के लिए न बताकर रखवाले विनम्र थे।
2. यहां तक ​​कि अगर कोई _does_ एक पीआर बढ़ाता है, तो इसका मतलब यह होगा कि फीचर का निरंतर रखरखाव अनुरक्षकों पर अधिक बोझ होगा, उन्हें मुख्य उत्पाद बनाए रखने से रोक देगा।
3. इस तरह के फ़ीचर का दुरुपयोग यार्न के नए जुमलों और / या अन्यथा यार्न के अपेक्षाकृत अकुशल उपभोक्ताओं द्वारा किया जाएगा, जो आगे चलकर 2 को नष्ट कर देगा।

किसी भी मामले में इस सुविधा की आवश्यकता के खिलाफ कम करने के लिए एक बेहतर, अधिक वास्तुशिल्प तरीका है।

मैंने इस कार्यक्षमता को प्राप्त करने के लिए yarn-add-no-save बनाया। इसे स्थानीय रूप से आपकी परियोजना या वैश्विक स्तर पर स्थापित किया जा सकता है:

$ yarn add yarn-add-no-save --dev
# or
$ yarn global add yarn-add-no-save

एक बार स्थापित होने के बाद आप बस चला सकते हैं:

$ yarn add-no-save <packages> # (yarn-add-no-save when installed globally)

मेरा उपयोग मामला उन मॉड्यूल का परीक्षण करने के लिए है जो peerDependencies घोषणा करते हैं,

$yarn add-no-save --help

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

यह बहुत सहायक है, विशेष रूप से सहकर्मी समर्थन। धन्यवाद।

इस सुविधा के लिए कई अच्छे तर्क हैं। यह इसे डिफ़ॉल्ट करने की तरह नहीं है, लोग इसे एक स्पष्ट ध्वज के पीछे होने के लिए कह रहे हैं कि केवल इसके लिए आवश्यक लोग इसका उपयोग करेंगे। वर्तमान में, कुछ अन्य की तरह, मुझे अन्य लाइब्रेरी संस्करणों के साथ CI के दौरान कुछ परीक्षण करने की आवश्यकता है जिन्हें मैं सहेजना नहीं चाहता । मैं समझ नहीं पा रहा हूँ कि यहाँ समझना कितना कठिन है।

मुझे yarn install xxx तब yarn remove xxx ।

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

मुझे yarn install xxx तब yarn remove xxx ।

वही

यहां ऐसा करने के लिए सक्षम होने के लिए उपयोग मामला है:

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

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

इस सुविधा को खोना हमारी परियोजना के लिए एक सीमित निर्णय लगता है, हालांकि हम वैकल्पिक दृष्टिकोणों का पता लगाना जारी रखेंगे।

इससे पहले कि मैं "अनुचर" उत्तर यहाँ पढ़ूँ, मुझे लगा कि मैं अब तक का सबसे जिद्दी व्यक्ति था।

लगभग 4 साल ... 🤦

"हठीलापन" वैसा नहीं है जैसा कि "एक डिज़ाइन दृष्टि का होना और किसी के लिए भी सब कुछ लागू न करना"।

"हठीलापन" वैसा नहीं है जैसा कि "एक डिज़ाइन दृष्टि का होना और किसी के लिए भी सब कुछ लागू न करना"।

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

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

Git ने दशकों पहले इस समस्या को हल कर लिया, पकड़ लिया! बस कुछ लेकर आओ! वह डिजाइन क्या है - सीमाओं को दरकिनार करने के बजाय उन्हें लड़ना (या उन्हें उपज देना)।

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

मुझे लगता है कि जब हम बस इसके चारों ओर जा सकते हैं तो हर कोई एक-दूसरे के खिलाफ एक संकीर्ण पहाड़ी को धक्का दे रहा है।