यार्न ब्लॉग पर आधारित:

जब आप कोई ऐसा पैकेज प्रकाशित करते हैं जिसमें एक यार्न.लॉक होता है, तो उस लाइब्रेरी का कोई भी उपयोगकर्ता इससे प्रभावित नहीं होगा। जब आप अपने एप्लिकेशन या लाइब्रेरी में निर्भरता स्थापित करते हैं, तो केवल आपकी खुद की यार्न.लॉक फ़ाइल का सम्मान किया जाता है। आपकी निर्भरताओं के भीतर लॉकफाइल को नजरअंदाज कर दिया जाएगा।

व्यक्तिगत पैकेज प्रकाशित करते समय यार्न.लॉक को बंडल करना आवश्यक नहीं लगता... यह पूरे रेपो के लिए एक विकास आर्टिफैक्ट है, इसलिए, इसे प्रत्येक पैकेज में रखने की आवश्यकता नहीं है।

@connectdotz किसी पुस्तकालय या प्रकाशित पैकेज के लिए इसकी आवश्यकता नहीं हो सकती है, लेकिन एक डॉकटर कंटेनर बनाने के लिए आप कहीं और तैनात करना चाहते हैं, यह निश्चित रूप से होगा।

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

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

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

यहां समाधान के लिए प्रति कार्यक्षेत्र में एक यार्न.लॉक फ़ाइल बनाने की आवश्यकता नहीं है, यह एक यार्न कमांड भी हो सकता है, जो किसी दिए गए कार्यक्षेत्र की पैकेजिंग की प्रक्रिया में मदद करता है, मांग पर कार्यक्षेत्र के लिए एक यार्न.लॉक फ़ाइल उत्पन्न करता है, आदि। ..

आशा है कि इसने उपयोग के मामले को स्पष्ट करने में मदद की ..

@netanelgilad विवरण के लिए धन्यवाद, यह स्पष्ट करने में मदद करता है कि आपका उपयोग मामला प्रकाशित करने के बारे में अधिक है। कृपया #4521 में चर्चा में शामिल हों ताकि हम उन्हें समेकित करना शुरू कर सकें।

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

छवि में आपके द्वारा बनाए जाने वाले पैकेज के लिए आपको केवल package.json की आवश्यकता होगी और यार्न केवल उन package.json फ़ाइलों के लिए पैकेज स्थापित करेगा, जिन्हें आपने कॉपी किया है, यहां तक ​​कि आप यार्न.लॉक में और भी बहुत कुछ शामिल हैं।

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

4206 संबंधित/डुप्लिकेट है, और वहां वर्णित उपयोग-मामला ठीक वही समस्या है जिसका हम सामना कर रहे हैं:

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

मेरे पास कार्यस्थानों के साथ समान समस्याएं हैं। मेरा प्रोजेक्ट एक web-app जो कई स्थानीय पैकेजों पर निर्भर करता है:

web-app/
|--node_modules/
|--packages/
|  |--controls/
|  |  |--src/
|  |  |--package.json
|  |--utils/
|     |--src/
|     |--package.json
|--src/
|--package.json
|--yarn.lock

कार्यस्थान पैकेज controls और utils प्रकाशित नहीं हैं और पथ द्वारा उपयोग किए जाते हैं। मुद्दा यह है कि मुझे controls पैकेज ( yarn pack ) जारी करने की आवश्यकता है और मैं इसे स्वयं नहीं बनाना/परीक्षण करना चाहता हूं। इसका मतलब है कि मैं yarn install अंदर web-app/packages/constols/ करना चाहता हूं। कार्यस्थानों के साथ यह शीर्ष-स्तरीय web-app/yarn.lock फ़ाइल का उपयोग शीर्ष-स्तर web-app/node-modules/ । इसलिए, यह web-app/packages/controls/package.json में निर्दिष्ट सबसेट के बजाय सभी पैकेजों को स्थापित करता है। लेकिन मुझे यह जाँचने की ज़रूरत है कि मेरे पैकेज में सभी आवश्यक निर्भरताएँ हैं जो स्वयं के package.json और अन्य कार्यस्थानों से लापता डिप्स को भरने के भाग्य से काम नहीं करता है।

2 संभावित समाधान हैं:

1. यदि यह रूट नहीं है, तो रूट के yarn.lock , लेकिन केवल स्थानीय package.json में निर्दिष्ट पैकेजों को स्थापित करें।
2. शीर्ष-स्तरीय कॉन्फ़िगरेशन की खोज न करें, लेकिन .yarnrc/.npmrc ।

इससे जूझ भी रहे हैं। हमारे पास हमारे एपीआई के साथ एक कोणीय सीएलआई प्रोजेक्ट है, इसलिए वे एक ही भंडार में हैं और फ्रंटएंड को हेरोकू में धक्का देने की कोशिश कर रहे हैं।

हम एक बिल्डपैक का उपयोग कर रहे हैं जो हरोकू को पहले फ्रंटएंड रिपॉजिटरी में कूदने के लिए कहता है: https://github.com/lstoll/heroku-buildpack-monorepo

समस्या यह है कि उस nohoist पैकेज के अंदर कोई yarn.lock नहीं है, इसलिए हरोकू सिर्फ npm के साथ स्थापित होता है और हम बंद वाले के बजाय सभी नए पैकेजों के साथ समाप्त होते हैं

आप केवल अलग-अलग पैकेजों के साथ वैश्विक यार्न.लॉक फ़ाइल का उपयोग कर सकते हैं। मैंने हाल ही में अपने डॉकरफाइल से इस तरह संपर्क किया है:

WORKDIR /app
ENV NODE_ENV=production

ADD yarn.lock /app/
ADD package.json /app/

# Only copy the packages that I need
ADD packages/my-first-package /app/packages/my-first-package
ADD packages/my-second-package /app/packages/my-second-package

RUN cd /app && yarn install --frozen-lockfile

यह केवल उन निर्भरताओं को स्थापित करेगा जो वास्तव में मेरे द्वारा कॉपी किए गए दो पैकेजों द्वारा उपयोग में हैं और किसी और द्वारा नहीं।

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

1. डॉकटर में केवल यार्न.लॉक, पैकेज.जेसन और यूआई पैकेज जोड़ें
2. yarn install --frozen-lockfile चलाएं
3. निर्माण प्रक्रिया चलाएँ
4. एक नया चरण शुरू करें और यार्न.लॉक, पैकेज.जेसन और आवश्यक रनटाइम पैकेज/वर्कस्पेस फ़ोल्डर जोड़ें
5. निर्मित आर्टिफैक्ट के लिए COPY --from=<stage>
6. yarn install --frozen-lockfile चलाएँ और RUN कमांड को प्रदर्शित करें।

और आप एक छोटे कंटेनर के साथ समाप्त होंगे जिसमें केवल आपकी यार्न.लॉक फ़ाइल में निर्दिष्ट निर्भरताएं होती हैं और उत्पादन में आवश्यक होती हैं।

@ जोहान्स-शारलाच
आप जो वर्णन कर रहे हैं उसके लगभग समान विधि का उपयोग करके मैंने समाप्त कर दिया है। मल्टीस्टेज बिल्ड एक अच्छी टिप है :)।

@connectdotz मुझे लगता है कि मेरी ओर से, इस मुद्दे को बंद किया जा सकता है और हम #4521 मुद्दे पर काम करना जारी रख सकते हैं। चूंकि मुख्य यार्न.लॉक फ़ाइल संकुल के सबसेट के साथ काम कर सकती है, ऐसा लगता है कि प्रति कार्यक्षेत्र एक यार्न.लॉक की तरह आवश्यक नहीं है (भले ही मुझे अभी भी लगता है कि यह एक बेहतर देव वर्कफ़्लो हो सकता है 😉)। लेकिन #4521 में मुद्दा अभी भी महत्वपूर्ण है, क्योंकि समाधान में हम यहां पहुंचे हैं, हमें डॉकरफाइल में प्रत्येक निर्भरता कार्यक्षेत्र का उल्लेख करने की आवश्यकता है, भले ही यार्न को अन्योन्याश्रितताओं और किसी दिए गए कार्यक्षेत्र को "विक्रेता" कैसे पता होना चाहिए।

मैंने पिछले कुछ दिनों में अपने मोनोरेपो को पहले लर्न और फिर यार्न कार्यक्षेत्र में बदलने की कोशिश की। यार्न ने आम तौर पर अधिक मज़बूती से काम किया और यह वास्तव में हमारी ज़रूरत के करीब है, विशेष रूप से हाल ही में yarn workspaces run <script> शुरूआत और wsrun जैसी अन्य अच्छी चीजों के साथ।

हालांकि, एकल yarn.lock एक दर्द बिंदु है:

• मुझे यकीन नहीं है कि हमारी मौजूदा लॉकफाइल्स को एक एकल में सही तरीके से कैसे माइग्रेट किया जाए, https://github.com/yarnpkg/yarn/issues/6563 देखें। हमारे पास वहां हजारों लाइनें हैं और मौजूदा पैकेजों को जोड़ने के रूप में कार्यस्थानों ने कई सूक्ष्म संस्करण मुद्दों को पेश किया है।
• केवल विशिष्ट पैकेज में निर्भरता स्थापित करना ("डी-होस्टिंग" / "वेंडरिंग") डॉकराइज़्ड बिल्ड अच्छी तरह से समर्थित नहीं है, ऊपर देखें (https://github.com/yarnpkg/yarn/issues/5428#issuecomment-403722271) या https: //github.com/yarnpkg/yarn/issues/4521।

आप यार्न कार्यक्षेत्र के बारे में क्या सोचेंगे,

• यदि आप अपने कार्यक्षेत्र में कुछ स्क्रिप्ट चलाना चाहते हैं, तो आप yarn workspaces run <script> ।
• यदि आप एक ही लॉक फ़ाइल और उत्थापन चाहते हैं (क्या दोनों आवश्यक रूप से एक साथ बंधे हैं?), यह आपका मूल package.json :
  json "workspaces": { "packages": ["packages/*"], "hoistDependencies": true }
• यदि आप अपनी वर्तमान लॉकफ़ाइल्स को एक फहराए गए ढांचे में माइग्रेट करना चाहते हैं, तो आप yarn workspaces hoist-dependencies चलाएंगे।

आदि। ये सिर्फ उदाहरण हैं और व्यवहार में, कुछ सुविधाओं को ऑप्ट-इन करने के बजाय ऑप्ट-आउट किया जा सकता है (उदाहरण के लिए, लोग एक yarn.lock और अब तक उत्थापन की उम्मीद करते हैं) लेकिन सामान्य विचार यह है कि कार्यक्षेत्र रेपो-वाइड कार्यों के लिए एक हल्का आधार बनें।

तुम क्या सोचते हो?

मेरा मानना ​​है कि यह सुविधा अनुरोध जिस समस्या का समाधान कर रहा है वह #4521 जैसी ही है। अनिवार्य रूप से @ johannes-scharlach का वर्णन करने के लिए एक आदेश निश्चित रूप से प्रति वर्कस्पेस लॉकफाइल से अधिक व्यवहार्य होगा।

नेस्टेड कार्यक्षेत्रों के लिए अभी एक

आप यार्न कार्यक्षेत्र के बारे में क्या सोचेंगे, यह सिर्फ एक छोटा कोर है - बिना किसी विशिष्ट कार्यक्षमता के पैकेज की घोषणा

कार्यस्थान बहुत अधिक नहीं बदलेगा, मुझे लगता है कि हम उनके वर्तमान इंटरफ़ेस से संतुष्ट हैं।

यदि आप अपने कार्यक्षेत्र में कुछ स्क्रिप्ट चलाना चाहते हैं, तो आप yarn workspaces run <script>

यह पहले से ही संभव है (v1.10, #6244)।

यदि आप अपनी वर्तमान लॉकफ़ाइल्स को एक फहराए गए ढांचे में माइग्रेट करना चाहते हैं, तो आप yarn workspaces hoist-dependencies चलाएंगे।

चूंकि हम कार्यक्षेत्र इंटरफ़ेस नहीं बदलेंगे, यह विपरीत होगा ( dehoistDependencies )।

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

इस मामले में, मुझे लगता है कि आपका उपयोग मामला ("केवल विशिष्ट पैकेज में निर्भरता स्थापित करना") yarn --focus को बढ़ाकर बेहतर हल किया जाएगा।

मुझे लगता है कि मूल प्रश्न यह है कि क्या कार्यक्षेत्र के लिए उत्थापन और एक एकल yarn.lock फ़ाइल सख्ती से आवश्यक है। मेरा मतलब है, क्या वास्तव में उन्हें परिभाषित करता है या यह "सिर्फ" पहली विशेषता है जो उन्हें ऐतिहासिक रूप से मिली है?

उदाहरण के लिए, हमारे उपयोग के मामले में, कार्यक्षेत्रों का सबसे अच्छा काल्पनिक व्यवहार होगा:

• दक्षता के लिए विकास समय पर node_modules लहराएं।
• स्थानीय yarn.lock फ़ाइलों को निर्माण के लिए रखें (हम डॉकर में विशिष्ट पैकेज बनाते हैं, कुछ ऐसा जो अन्य लोगों ने इस धागे में भी उल्लेख किया है) और यह भी कि पैकेज उनके विशिष्ट संस्करणों को लॉक कर सकते हैं। #6563 भी देखें।
• yarn workspaces run <script> माध्यम से स्क्रिप्ट चलाएं, भले ही आपको उत्थापन की आवश्यकता न हो (या इससे बचना चाहिए)।

होस्टिंग को nohoist साथ अक्षम किया जा सकता है, run को केवल कमांड का उपयोग न करके "अक्षम" किया जा सकता है लेकिन एकल yarn.lock फ़ाइल को "अक्षम" करना संभव नहीं है, और मैं ' मुझे यकीन नहीं है कि यह इतनी मुख्य विशेषता है कि इसे अक्षम नहीं किया जा सकता है या अगर इसे अभी तक पर्याप्त अनुरोध नहीं किया गया है :)

मुझे लगता है कि इसे हल करने का सबसे अच्छा तरीका होगा yarn install --app-mode package@version

इस तरह, आप अपने ऐप को एक निश्चित संस्करण पर प्रकाशित करते समय बस कार्यक्षेत्र लॉकफ़ाइल्स की प्रतिलिपि बना सकते हैं, और app-mode में स्थापित बंडल लॉकफ़ाइल का सम्मान करेंगे।

यार्न को संपूर्ण लॉकफाइल स्थापित करने की आवश्यकता नहीं है; यह आसानी से उस पैकेज से संबंधित निर्भरता ग्राफ के केवल हिस्से को निकालने में सक्षम होना चाहिए।

वास्तव में यह अब भी मैन्युअल रूप से करना काफी आसान हो सकता है:

• सीधे रजिस्ट्री से पैकेज ज़िप डाउनलोड करें (यार्न का कोई समकक्ष नहीं है, npm करता है: npm pack package@version )
• gzip को node_modules/package में निकालें
• नोड_मॉड्यूल/पैकेज में सीडी
• रन यार्न इंस्टॉल - वहां से उत्पादन (यह बंडल लॉकफाइल का सम्मान करेगा)

संपादित करें: दुर्भाग्य से यह सब गलत है, क्योंकि वर्कस्पेस लॉकफाइल में वर्कस्पेस के भीतर पैकेज के संस्करण शामिल नहीं हैं, जो ऐप पैकेज की निर्भरता हो सकती है। कार्यक्षेत्र लॉकफ़ाइल्स से ऐप लॉकफ़ाइल्स बनाते समय कॉपी करने के अलावा कुछ और शामिल करने की आवश्यकता होगी।

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

यहाँ @samuela की तुलना में बहुत समान उपयोग का मामला है! यह बड़े पैमाने पर मददगार होगा!

मेरा उपयोग-मामला दूसरे, "वास्तविक" की तुलना में हँसने योग्य लग सकता है। लेकिन मेरे पास कुछ बर्तनों के लिए एक मोनोरेपो है - इस मामले में प्रतिक्रिया हुक - अंदर packages/* ।

मेरे पास packages/* बगल में दूसरा कार्यक्षेत्र है, और वह है local/* । यह वास्तव में gitignore पर है, और विचार यह है कि कंपनी के डेवलपर्स वहां जो चाहें कर सकते हैं, उदाहरण के लिए वहां create-react-app ऐप्स डालें और विकास के दौरान हुक का परीक्षण करें।

अब, हालांकि local/* पैकेज gitignore पर हैं, रूट yarn.lock बस फूला हुआ और प्रदूषित है - और स्थानीय कार्यक्षेत्रों के कारण git में चेक किया गया है।

मैं जो चाहता हूं वह यह निर्दिष्ट करने का एक तरीका है कि कुछ कार्यक्षेत्र कुछ विशिष्ट लॉकफाइल का उपयोग करेंगे, उदाहरण के लिए कुछ मैपिंग:

  "workspaces": {
    "packages": [
      "packages/*",
      "local/*"
    ],
    "lockfiles": {
      "local/*": "./local.yarn.lock"
    }
  }

या यहां तक ​​​​कि "_this_ वर्कस्पेस से लॉकफाइल में कुछ भी न डालें" निर्दिष्ट करने का एक तरीका भी।

लेकिन हाँ, मेरा पहला गंभीर उपयोग-मामला नहीं है :)

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

आपने इसे भुनाया - जैसा कि मैं इसे देखता हूं, यार्न.लॉक फ़ाइल के बहुत ही मुख्य लाभों में से एक फ्रोजन-डिप प्रोडक्शन बिल्ड बनाने के लिए है! क्या यार्न के निर्माता यह भूल गए?

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

फिर भी प्रति कार्यक्षेत्र लॉकफ़ाइल्स जनरेट करने का विकल्प रखने का एक अन्य कारण: Google ऐप इंजन बिना लॉक फ़ाइल (एनपीएम/यार्न) के एक नोड सेवा शुरू करने से इनकार करता है। यह उनकी ओर से उत्कृष्ट देवोप्स है, लेकिन हमारे लिए एक दर्द है। अब तक हमारे पास विकल्प हैं:

• env vars के साथ सभी को तैनात करें जो दर्शाता है कि हमारा मतलब किस सेवा से है और हमारे yarn start (एकमात्र समर्थित प्रवेश बिंदु) को env vars के आधार पर शाखा में संशोधित करें
• बिल्ड स्क्रिप्ट को मुख्य लॉकफाइल को प्रत्येक कार्यक्षेत्र में कॉपी करें और केवल उस सेवा को तैनात करें जिसमें हम रुचि रखते हैं। (धन्यवाद @ johannes-scharlach)

अंततः मुझे लगता है कि एक yarn install --workspace-lockfile कमांड जो प्रति कार्यक्षेत्र लॉकफाइल्स उत्पन्न करता है, वह सबसे अच्छा समाधान होगा।

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

तो हमारे पास पहले से ही कुछ मोनो रेपो हैं, और हमारे पास कुछ रेपो हैं जिनमें केवल एक पैकेज है। ये सभी प्रकाशित हैं और इसलिए एक साथ उपयोग किए जा सकते हैं, हालांकि कई बार ऐसा होता है जब उन्हें स्थानीय रूप से और सिम्लिंक करना बहुत उपयोगी होता है।

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

लेकिन हम एक समस्या का सामना कर चुके हैं जिसे हम हल नहीं कर सकते हैं, निर्भरता को संपादित करना स्थानीय यार्न लॉक फ़ाइल को अपडेट नहीं करता है, यह हमेशा खाली मोनो रेपो के लिए रूट को अपडेट करता है हम अपडेट निर्भरता को अपडेट नहीं करते हैं (इसमें सब कुछ है /packages gitignored.

मोनो रेपो रूट पर लॉक फ़ाइल को न फहराने का विकल्प होना बहुत अच्छा होगा और उन्हें पैकेज स्तर पर लिखना होगा।

एक नोट के रूप में मैं भी तैनाती में आया हूं और डॉकर के आसपास के मुद्दों का निर्माण किया है जिनका दूसरों ने उल्लेख किया है और यह भी हल करेगा!

यह सुविधा मेरे लिए भी बहुत मूल्यवान होगी। मेरे मामले में मेरे पास विभिन्न प्लेटफार्मों पर तैनात कुछ पैकेजों के साथ एक मोनोरेपो है। एक Now.sh के साथ तैनात एक Next.js ऐप है और दूसरा Firebase पर तैनात क्लाउड-फ़ंक्शंस का एक समूह है।

इन दोनों परिनियोजन में सोर्स कोड को बंडल किया जाता है और क्लाउड में इंस्टॉल और बिल्ड के लिए अपलोड किया जाता है। स्रोत के साथ जाने के लिए yarn.lock फ़ाइल नहीं होने का मतलब है कि पैकेज.json में संस्करणों का उपयोग करके निर्भरताएं स्थापित की गई हैं और कोई भी संस्करण लॉक नहीं है।

मैं प्रत्येक कार्यक्षेत्र में यार्न.लॉक फ़ाइलों को सक्षम करने में सक्षम होना भी पसंद करूंगा।

मुझे एहसास है कि यार्न वर्कस्पेस ज्यादातर मोनोरेपो के लिए हैं, लेकिन हमारे उपयोग का मामला @LeeCeneler के समान ही है।

मूल रूप से, हमने एक रिएक्ट घटक पुस्तकालय बनाया है जिसका उपयोग हम विभिन्न परियोजनाओं में एक निर्भरता के रूप में करते हैं (जिसमें सभी का अपना रेपो होता है)। यार्न वर्कस्पेस का उपयोग करके हम घटक पुस्तकालय के स्थानीय संस्करण को आसानी से संदर्भित कर सकते हैं और हमारे अन्य प्रोजेक्ट के स्थानीय संस्करण में परिवर्तन जल्दी से प्रचारित कर सकते हैं। जब हम उत्पादन पर जोर देते हैं तो हमें package.json को संशोधित करने की आवश्यकता नहीं होती है क्योंकि निर्भरता library: "*" बिना किसी बदलाव के काम करती है। हमारा एकमात्र मुद्दा यह है कि, यार्न लॉक फाइलों के बिना, प्रत्येक प्रोजेक्ट के उत्पादन संस्करण विभिन्न पैकेज संस्करणों का उपयोग कर समाप्त हो सकते हैं।

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

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

इसे (थोड़ा पुराना) मुद्दा लाने के लिए खेद है, लेकिन मेरे पास एक उपयोग का मामला भी है जिसमें यह सहायक होगा। मेरे पास 10 या तो माइक्रोसर्विसेज हैं जिन्हें स्वतंत्र रूप से होस्ट और विकसित किया गया है, लेकिन एक केंद्रीय कार्यक्षेत्र रेपो होना अच्छा होगा जहां आप सभी फ़ोल्डरों में निर्भरता स्थापित करने के लिए yarn install टाइप कर सकते हैं और फिर yarn start एक स्क्रिप्ट चलाने के लिए जो सभी माइक्रोसर्विसेज को शुरू करेगी। यह कुछ ऐसा है जो अपेक्षाकृत सरल लिपि के साथ किया जा सकता है लेकिन यह यार्न वर्कस्पेस के साथ भी करने योग्य लग रहा था लेकिन मैं यार्न का सम्मान करते हुए इसे काम नहीं कर सका। प्रत्येक माइक्रोसर्विस में लॉक

@nahtnam मुझे लगता है कि यार्न 1.x मोनोरेपो का विचार थोड़ा अलग है। यह एक छत के नीचे स्वतंत्र परियोजनाओं के बारे में नहीं है, यह एक विलक्षण बड़ी परियोजना के बारे में है जिसमें इसके कुछ घटक सामने आए हैं (जिन्हें कार्यक्षेत्र कहा जाता है)। ये घटक पूरी तरह से स्वतंत्र नहीं हैं, लेकिन इनका उपयोग इस तरह किया जा सकता है: बैबेल कंपाइलर एक बड़ी इकाई के रूप में और preset-env उप-मॉड्यूल के रूप में। साथ ही, वे इस अर्थ में सजातीय हैं कि उनकी निर्भरताएं एकीकृत हैं: यदि कुछ पैकेज core-js पर निर्भर करते हैं, तो यह उनमें से हर एक में समान core-js संस्करण होना चाहिए, क्योंकि आप नहीं कर सकते एक ही रूट लॉक फ़ाइल के साथ विभिन्न संस्करणों को लॉक करें, न ही यह समझ में आता है कि परियोजना के हिस्से विभिन्न संस्करणों पर निर्भर हैं। और क्योंकि यह एक परियोजना है, इसके सभी घटक स्वतः जड़ node_modules से जुड़ जाते हैं, जो पूरी तरह से स्वतंत्र परियोजनाओं के लिए अजीब है।

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

एकमात्र सवाल यह है कि स्क्रिप्ट चलाने में कौन सा टूल मदद करेगा। Lerna एक उत्तर हो सकता है क्योंकि यह यार्न से बंधा नहीं है।

@ the-spyke इतना ही नहीं। yarn workspaces भी हल करता है, विकास के लिए मॉड्यूल को उसी तरह जोड़ता है जैसे npm link करता है, यही मुख्य कारण है कि हम इसका उपयोग कर रहे हैं। कुछ मामलों में npm link ठीक से काम नहीं कर रहा है।

@ the-spyke धन्यवाद! किसी कारण से, मैंने सोचा कि इसे फ़्लिप किया गया था (लर्न बनाम यार्न वर्कस्पेस)। मैंने लर्न में देखा और ऐसा लगता है कि यह मेरी समस्या हल करता है

मैं जिस प्रत्येक प्रोजेक्ट पर काम कर रहा हूं, उसके लिए वर्कस्पेस का उपयोग करना समाप्त कर दिया, क्योंकि एक अलग utilities पैकेज होना कितना आसान है जिसे मैं जरूरत पड़ने पर अपडेट कर सकता हूं (भले ही यह प्रकाशित हो), और तथ्य यह है कि अगर मैं कुछ पैकेज (अनिवार्य रूप से मुझे एक ही समय में दो शाखाओं पर काम करने की इजाजत देता हूं, जो मेरे लिए अनसुना था), और जब भी मैं अपने utilities से पैकेज का उपयोग करना चाहता हूं, तो मुझे निर्भरता को पुनर्स्थापित करने की आवश्यकता नहीं है। package.json स्वचालित आईडीई आयात के लिए); सब कुछ बस काम करता है। @ the-spyke एक अच्छा बिंदु बनाता है, शायद independent projects under one roof कार्यक्षेत्र का उद्देश्य नहीं है, और फिर भी मैं यहां जो कुछ कर रहा हूं वह काफी है: मेरे पास एक monorepo-base भंडार है, जो packages फ़ोल्डर को शामिल नहीं करता है , जबकि packages तहत प्रत्येक फ़ोल्डर एक अलग स्वतंत्र गिट रेपो है।

बेशक यह मुझे इस सूत्र के विषय पर लाता है; चूंकि मैं सभी पैकेजों को एक रेपो के रूप में प्रतिबद्ध नहीं करता, रूट-लेवल yarn.lock अर्थहीन है। मैं सब कुछ स्थापित करने के लिए --no-lockfile का उपयोग कर रहा हूं, और हाल ही में class-validator विरोधाभासी संस्करणों के साथ एक समस्या आई है। अभी के लिए मैं सभी विभागों को विशिष्ट संस्करणों में लॉक कर दूंगा (ईमानदारी से, नियंत्रण का वह स्तर मेरे लिए अधिक समझ में आता है) और देखें कि यह कैसे काम करता है। मैं पूरी चाल फिर से पढ़ूंगा, हो सकता है कि कुछ सुझाव हैं जो मैं अपने उपयोग के मामले के लिए उपयोग कर पाऊंगा।

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

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

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

यहां एक समाधान है जिस पर हम पहुंचे - मौजूदा डॉकर वर्कफ़्लो पर न्यूनतम प्रभाव के साथ।

1. ln project/yarn.lock packages/package1/yarn.lock - प्रत्येक पैकेज में रूट yarn.lock से एक हार्ड सिमलिंक बनाएं।
2. जोड़े COPY yarn.lock . प्रत्येक के लिए packages/package1/Dockerfile
3. yarn install डॉकर के अंदर

लाभ :

• अपने संपूर्ण मोनोरेपो को एक छवि परत में कॉपी करने की आवश्यकता नहीं है
• अपने पैकेज स्तर Dockerfiles को रूट पर एकल Dockerfile में मर्ज करने की आवश्यकता नहीं है
• मूल रूप से कार्यक्षेत्र लॉकफ़ाइल्स की आवश्यकता को पूरा करता है

नुकसान :

• --frozen-lockfile काम नहीं करता। कार्यस्थानों पैकेज में शामिल नहीं कर रहे हैं के रूप में yarn.lock , इसलिए धागा एक पैकेज आप के लिए "जोड़ा" है देखता है package.json कि में मौजूद नहीं है yarn.lock

यह एक मामूली नुकसान है, भले ही आप yarn --frozen-lockfile को अपने CI/CD पाइपलाइन में पहले चरण के रूप में निष्पादित करके इसे प्राप्त कर सकते हैं

संपादित करें:
एक तरफ के रूप में, मुझे वास्तव में लगता है कि स्थापित करने पर यार्न दस्तावेज़ थोड़ा स्पष्ट हो सकता है कि पैकेज रिज़ॉल्यूशन प्रक्रिया द्वारा लॉकफाइल का उपयोग कैसे किया जाता है।

संपादित करें:
तो पता चलता है कि गिट वास्तव में हार्ड-लिंक का समर्थन नहीं करता है, यह केवल सॉफ्ट सिम्लिंक का समर्थन करता है, इसलिए यह रणनीति काम नहीं करेगी।

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

@ डैन-कुक आपकी अंतर्दृष्टि के लिए बहुत बहुत धन्यवाद, बहुत सराहना की!

@ डैन-कुक, यह डॉकर की परत कैशिंग को तोड़ देता है क्योंकि किसी भी कार्यक्षेत्र में एक नई निर्भरता सभी डॉकरफाइल के लिए इंस्टॉल परत को अमान्य कर देगी।

@migueller यदि इंस्टॉल परत नहीं बदलनी चाहिए, तो आपको सभी पैकेजों के लिए एक लॉक फ़ाइल का उपयोग नहीं करना चाहिए। एकल विशाल सूची में निर्भरता को समतल करना और फहराना कार्यस्थानों का संपूर्ण उद्देश्य है। ऐसा नहीं है कि यह डॉकर कैश को "ब्रेक" करता है, कैश अमान्य है क्योंकि वास्तविक निर्भरता package.json में निर्दिष्ट नहीं है, इसलिए आपके पैकेज का अंतिम कोड yarn.lock की सामग्री पर निर्भर करता है। परिणामस्वरूप आपको yarn.lock में हर बदलाव पर सभी पैकेजों को फिर से बनाना होगा और डॉकर सब कुछ ठीक करता है। और यह where every package is built without the cache जैसा नहीं है क्योंकि सभी बिल्ड yarn install साथ परत का पुन: उपयोग कर सकते हैं (शायद आपको इसे सेट करने की आवश्यकता होगी)।

@ मिगुएलोलर
सही। सौभाग्य से हम अक्सर नई निर्भरताएँ नहीं जोड़ते हैं, इसलिए यह केवल एक बार स्प्रिंट करने के बाद ही एक मुद्दा होगा।

और फिर भी, डॉकर में पुनरुत्पादित निर्भरताओं के लिए भुगतान करने के लिए इसकी एक छोटी सी कीमत (हमारे लिए) है

@ द-स्पाइक, वास्तव में। यही कारण है कि यह समस्या प्रति पैकेज एक व्यक्तिगत लॉकफाइल होने के बारे में है। इस तरह, कैश्ड परत केवल तभी अमान्य होती है जब पैकेज की निर्भरता बदल जाती है और अन्य पैकेजों से स्वतंत्र होती है।

हो सकता है कि इस चर्चा को npm पर ले जाना भी उचित हो, जो v7.0 से शुरू होने वाले कार्यक्षेत्रों का भी समर्थन करता है।

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

"सभी निर्भरताओं को विशिष्ट संस्करण में लॉक करना" को पिनिंग कहा जाता है; दुर्भाग्य से, यह चीजों को संभावित रूप से टूटने से नहीं रोकेगा यदि उप- निर्भरता अद्यतन (लेख के अंतिम पैराग्राफ यहां ), जिसे मैंने नहीं माना है। ऐसा होने से रोकने के लिए लॉकफाइल का ठीक यही मतलब है।

मैंने अतीत में कई मौकों पर अपडेट को तोड़ने में पर्याप्त घंटे से अधिक समय बर्बाद किया है; मैं मोनोरेपो में lockfile का उपयोग करने के साथ प्रयोग करूंगा, क्योंकि मैं मामूली अपडेट के कारण अदृश्य बग के बजाय मर्ज संघर्ष और संगठनात्मक सिरदर्द से निपटना चाहता हूं।

ऊपर कहा गया है, मैं इस मुद्दे पर किसी भी प्रगति की प्रतीक्षा कर रहा हूं

@migueller व्यक्तिगत लॉक-फाइलों का अर्थ है व्यक्तिगत यार्न मोनोरपोस। आपके पास वर्कस्पेस के लिए लॉक-फाइल नहीं हो सकती है क्योंकि यह मोनोरेपो में डीपीएस एकरूपता को तोड़ती है। यदि आप ऐसा करना चाहते हैं, तो आप यार्न मोनोरेपो के मूल विचार से दूर जा रहे हैं: यह अलग-अलग कार्यक्षेत्रों में अलग-अलग संस्करण (और यहां तक ​​​​कि पूरे उपट्री) होने के बजाय रूट में एक फ्लैट सूची में डिपो को एकीकृत करने, उठाने और कम करने के बारे में है। .

@ the-spyke लेकिन मूल मुद्दा बिल्कुल विपरीत है। प्रति कार्यक्षेत्र एक लॉक फ़ाइल।

मैं यह समझने में असफल रहा कि आपके पास प्रति वर्कस्पेस लॉकफाइल कैसे नहीं हो सकता है।

यह मोनोरेपो में डीप एकरूपता को तोड़ता है? विकास के लिए निश्चित। लेकिन साझा निर्भरता का पूरा उद्देश्य खिड़की से बाहर हो जाता है जब आपको अपने प्रत्येक कार्यक्षेत्र से हल्की सूक्ष्म सेवाओं को तैनात करना चाहिए

साझा, फहराए गए डिप्स केवल विकास में समझ में आता है।

डॉकर में रहने के लिए कार्यक्षेत्र के लिए, इसे लॉकफाइल की आवश्यकता होती है।

@ डैन-कुक जैसा कि आप देख सकते हैं , 2018 में भी मेरे पास यह मुद्दा था, लेकिन अब मेरी राय अलग है।

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

उसी समय, यदि आप माइक्रोसर्विसेज (एमएस) विकसित कर रहे हैं तो 2 संभावित स्थितियां हैं:

1. स्वतंत्र परियोजनाएं। कुछ एमएस विकास में हैं, कुछ वर्षों में छुआ नहीं गया था। इस मामले में वे पूरी तरह से स्वतंत्र हैं। UserService का उपयोग करके [email protected] और MessagesService का उपयोग करके [email protected] । यह इतनी आसान दुनिया नहीं है, जहां आप सिर्फ वर्कस्पेस से फोल्डर को रूट से लिंक करते हैं node_modules । तो, रूट लॉक-फाइल होने का कोई मतलब नहीं है। अलग फाइलें (रूट) बनाएं और उन्हें स्वतंत्र रूप से प्रबंधित करें। इसे यार्न डॉक्स में Multirepo कहा जाता है। लेकिन अब आप जो कह रहे हैं वह है "मैं सुविधा के लिए रूट फ़ोल्डर से विभिन्न फ़ोल्डरों में कार्य चलाना चाहता हूं"। और यह बिल्कुल अलग विषय है।

2. एकीकृत निर्भरता वाली परियोजनाएं जैसे जेस्ट/बेबेल/आदि। यही वह है जिसके लिए कार्यस्थान बनाए गए थे, लेकिन एमएस में अतिरिक्त आवश्यकताएं हैं। CI चरणों के दौरान जैसे लाइनिंग और परीक्षण सभी ठीक काम करता है क्योंकि यह उसी तरह काम करता है जैसे आप एक डेवलपर मशीन पर करते हैं: यार्न द्वारा रूट नोड_मॉड्यूल्स में स्थापित डिप्स और चपटा हो जाता है। इसके अलावा, आप समवर्ती निर्माण को गति देने के लिए संभवतः yarn install चरण को कैश कर सकते हैं।

   उत्पादन में यह पूरी तरह से अलग है: इससे शुरू होकर आपको केवल एक कार्यक्षेत्र के लिए विवरण की आवश्यकता होती है और उस utils पैकेज को कैसे स्थापित किया जाए? क्या इसे टारबॉल के रूप में लिंक या डाउनलोड किया जाना चाहिए? इसलिए, आपको वास्तव में जो चाहिए वह प्रति कार्यक्षेत्र लॉक-फाइल नहीं है, लेकिन yarn install --prod <workspace> जैसी कमांड है जिसे आप कार्यक्षेत्र निर्दिष्ट कर सकते हैं और यह केवल उत्पादन डिपो स्थापित करेगा और साथ ही अन्य संदर्भित कार्यस्थानों को अनदेखा करेगा। जैसे अगर मेरा data WS utils WS पर निर्भर करता है, लेकिन logging WS पर नहीं, तो logging स्वयं और उसके विवरण node_modules में प्रकट नहीं होने चाहिए

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

   और अंत में आपने फोकस्ड वर्कस्पेस को मल्टीरेपोस के लिए बिल्कुल लागू किया है।

तो, मैं यह क्या कह रहा था कि शायद समस्या वैसी नहीं दिखती जैसी यह है।

@the-स्पाईके
जो आप कह रहे हैं, वो मुझे समझ आ रहा है। मुझे लगता है कि यह निश्चित रूप से नीचे आता है कि यह परिणाम कैसे प्राप्त किया जाता है। शायद प्रति कार्यक्षेत्र एक लॉकफाइल वास्तव में वांछित परिणाम प्राप्त करने का सबसे अच्छा तरीका नहीं है। आपने कुछ सही बातें कहीं।

इसका निश्चित रूप से वैसे भी "एक आकार सभी फिट बैठता है" समाधान नहीं है

@ the-spyke, आप अच्छे अंक लाते हैं। शायद अधिक विचार करने की आवश्यकता है कि यार्न कार्यक्षेत्रों को हल करने के लिए किन समस्याओं को हल करने के लिए डिज़ाइन किया गया था और यदि बड़े मोनोरेपो को प्रबंधित करने के लिए इसका उपयोग उस डिज़ाइन के साथ गठबंधन किया गया है।

मैं उत्सुक हूं कि आप इस तरह के परिदृश्य को कैसे हल करेंगे:

.
└── packages
    ├── app1
    ├── app2
    ├── lib1
    ├── lib2
    └── lib3

lib3 एक साझा पुस्तकालय है और यह app1 और app2 पर निर्भर है। lib1 का उपयोग केवल app1 द्वारा किया जाता है और lib2 का उपयोग केवल app2 द्वारा किया जाता है। आपके सुझावों के आधार पर, lib1 और app1 अपने स्वयं के कार्यक्षेत्र में अपने स्वयं के लॉकफ़ाइल के साथ और lib2 और app2 । अब, प्रश्न यह है कि lib3 क्या किया जाए यदि _both_ app1 और app2 इस पर निर्भर हैं? शायद कोई ऐसा कर सकता है ताकि दोनों कार्यक्षेत्र ( app1 और app2 ) अपने कार्यक्षेत्र में lib3 जोड़ सकें और फिर प्रत्येक ऐप में yarn install सकें? क्या यार्न इसकी अनुमति देता है? यदि कोई app1 और app2 को स्थानीय रूप से विकास में चलाना चाहता है तो क्या कोई विरोध होगा (शायद app1 एक रिएक्ट ऐप है और app2 एक ग्राफ़क्यूएल एपीआई है) ? ऐसा लगता है कि यह काम कर सकता है।

अगला प्रश्न यह होगा कि "इस विधि से फहराने के लाभ कैसे प्राप्त होते हैं?" उदाहरण के लिए, यदि app1 और app2 बहुत सारी सामान्य निर्भरताएँ साझा करते हैं, तो उन्हें फहराना अच्छा होगा। मैं देख सकता हूं कि यह कैसे दायरे से बाहर हो सकता है, और यार्न पीएनपी द्वारा हल की जाने वाली एक समस्या है (यह फाइलों को नोड_मॉड्यूल्स में कॉपी नहीं करता है और इसके बजाय एक साझा कैश है)।

मैं इसे एक शॉट देने जा रहा हूं और वापस रिपोर्ट करूंगा। अगर यह काम करना समाप्त कर देता है, तो शायद हम यार्न वर्कस्पेस का गलत इस्तेमाल कर रहे हैं ...

संपादित करें: मैंने इसे आजमाया, और यह काम करता है।

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

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

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

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

मोनोरेपो चलाने के साथ आने वाली कई अन्य समस्याएं हैं। उदाहरण के लिए, निर्भरता को ट्रैक करने और केवल सीआई में समय बचाने के लिए बदली गई चीजों के पुनर्निर्माण के बारे में क्या? यार्न वर्कस्पेस आपको निर्भरता ग्राफ से पूछताछ करने में मदद कर सकता है। उदाहरण के लिए, लर्ना ऐसा करती है, ताकि टोपोलॉजिकल सॉर्टिंग कमांड को चलाया जा सके। यार्न v2 वास्तव में आपको निर्भरता ग्राफ को भी क्वेरी करने देता है। पैकेज मैनेजर पीएनपीएम भी यही करता है। लेकिन मैं तर्क दूंगा कि मोनोरेपो की जटिलता के आधार पर कोई उसके लिए बनाए गए टूल (पैकेज मैनेजर नहीं) जैसे Bazel , Pants , Buck , आदि का प्रयास करना चाह सकता है।

@migueller आपकी आवश्यकताओं से मैं देखता हूं कि आपको सख्ती से स्वतंत्र पैकेज या अन्य विदेशी चीजों की आवश्यकता नहीं है, आप स्लिमर डेवलपर इंस्टॉल भी चाहते हैं। ऐसे मामले में आपको नियमित यार्न मोनोरेपो से शुरू करना चाहिए: सिंगल रूट और सभी पैकेज वर्कस्पेस के रूप में। आपके पास तेज़ इंस्टॉलेशन समय होगा, डिस्क का कम उपयोग होगा, और app1 स्थानीय लिंक किए गए lib1 और lib3 । केवल नकारात्मक पक्ष अधिक बार सीआई कैश अमान्य होगा क्योंकि lib1 लिए एक devDep के अलावा साझा yarn.lock अपडेट हो जाएगा। लेकिन आमतौर पर आप उन निर्भरता को अपडेट नहीं करते हैं जो अक्सर इस ट्रेडऑफ़ के बारे में अधिक चिंता करने के लिए होती हैं।

lib1 lodash@^4.5.0" and lib2 may depend on lodash@^4.10.0" पर निर्भर हो सकता है। मोनोरेपो के मामले में आप lodash एकल संस्करण का उपयोग करना चाहते हैं, इसलिए यार्न दोनों विशिष्टताओं के लिए नवीनतम संगत कुछ स्थापित करेगा जैसे `

ऐसी स्थितियाँ भी हैं जहाँ स्वतंत्र टीमें स्वतंत्र परियोजनाएँ विकसित करती हैं। इस मामले में proj1 [email protected] साथ proj2 साथ [email protected] पर रहना चाह सकते हैं और इसे अपने स्वयं के कैडेंस के साथ अपडेट कर सकते हैं। बेशक, आप lodash@~4.5.0 जैसे अधिक सख्त विनिर्देशों का उपयोग करके इसे प्राप्त कर सकते हैं, लेकिन यह अभी भी दूसरे स्तर की निर्भरता को बहुत जल्दी अपडेट कर सकता है। तो, पूरी तरह से उन परियोजनाओं में पूरी तरह से असंबंधित हो सकता है, बस एक गिट रेपो के अंदर हुआ। इस मामले में उन्हें एक साझा लॉक-फ़ाइल के लिए यार्न मोनोरेपो और ट्रेड-ऑफ स्वतंत्रता के रूप में बाध्य करने का कोई कारण नहीं है। बस उनके साथ वैसा ही व्यवहार करें जैसे वे हैं: परियोजनाओं को उनके स्वतंत्र जीवन के साथ अलग करें। और इसे मल्टीरेपो कहा जाता है। यूनिक्स पर आपकी सभी निर्देशिकाएं / अंतर्गत हैं, लेकिन इसका मतलब यह नहीं है कि आपके पीसी पर सभी संभावित जेएस परियोजनाएं एक मोनोरेपो होनी चाहिए :-)

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

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

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

{
  "workspaces": [
    "../lib1",
    "../lib3"
  ]
}

हमारे पास @migueller के समान उपयोग का मामला है और यार्न के लिए कार्यक्षेत्रों के कई सेटों का समर्थन करने के लिए एक संभावित विचार है, जैसे:

{
  "workspaces": {
    "frontend-app": ["frontend", "common"],
    "backend-app": ["backend", "common"]
  }
}

यार्न दो अतिरिक्त लॉक फाइलों को बनाए रखेगा (मुझे लगता है कि मुख्य yarn.lock अभी भी मौजूद होगा):

.
└── monorepo/
    ├── yarn.frontend-app.lock
    ├── yarn.backend-app.lock
    └── packages/
        ├── frontend
        ├── backend
        └── common

डॉकर छवि बनाते समय, उदाहरण के लिए, फ्रंटएंड के लिए, हम एक संदर्भ (जैसे, टार के माध्यम से ) बनाएंगे जिसमें यह शामिल है:

.
└── <Docker build context>/
    ├── yarn.frontend-app.lock
    └── packages/
        ├── frontend
        └── common

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

(कुछ ऐसा ही यहां भी पोस्ट किया गया था।)

ऐसा लगता है कि आपको प्रति कार्यक्षेत्र लॉक फ़ाइल की आवश्यकता नहीं है, लेकिन इसके बजाय आपको परिनियोजन के लिए प्रति कार्यक्षेत्र नोड_मॉड्यूल की आवश्यकता है

@gfortaine , यदि आप चर्चा पढ़ते हैं तो आप महसूस करेंगे कि वास्तव में ऐसा नहीं है। एक अलग लॉकफाइल होने के कारण का इंस्टॉलेशन से कोई लेना-देना नहीं है, बल्कि एक लॉकफाइल है जो केवल एक विशिष्ट पैकेज के बदलने पर ही बदलता है। एक शीर्ष-स्तरीय लॉकफ़ाइल _every_ कार्यक्षेत्र निर्भरता परिवर्तन के साथ बदल जाएगी, लेकिन एक एकल पैकेज में स्कोप की गई लॉकफ़ाइल केवल तभी बदलेगी जब _that_ पैकेज की निर्भरताएं बदल जाएंगी।

उल्लेखनीय है कि यह उपयोगकर्ता-भूमि में किया जा सकता है। @yarnpkg/lockfile पैकेज का उपयोग करके कोई शीर्ष-स्तरीय लॉकफ़ाइल को पार्स कर सकता है, और फिर yarn workspaces info का उपयोग करके कोई कार्यक्षेत्र निर्भरता निर्धारित कर सकता है। इस जानकारी का उपयोग करके, प्रत्येक कार्यक्षेत्र के package.json के साथ, कोई भी व्यक्ति प्रति कार्यक्षेत्र एक लॉकफ़ाइल उत्पन्न कर सकता है। फिर, कोई इसे रेपो में postinstall स्क्रिप्ट के रूप में सेट कर सकता है ताकि उन व्यक्तिगत लॉकफाइल्स को शीर्ष-स्तर के साथ सिंक में रखा जा सके।

मैं इसे बनाने में एक स्टैब ले सकता हूं और अपने निष्कर्षों के साथ वापस रिपोर्ट कर सकता हूं।

ऐसा लगता है कि मैंने अभी-अभी pnpm के लिए यह कार्यान्वयन पाया है: @ pnpm/मेक-समर्पित-लॉकफाइल

आशा है कि यह मदद करता है

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

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