Cli: [बग] कार्यस्थानों को प्रलेखित नहीं किया जाता है, काम पर नहीं आते हैं

हाय @justinfagnani प्रतिक्रिया के लिए धन्यवाद

वर्तमान या नए डॉक्स में कार्यक्षेत्रों का कोई उल्लेख नहीं है

यह npm v7 के साथ बंडल किए गए दस्तावेज़ में है, इसे पढ़ने के लिए आप इसे चला सकते हैं:

• टर्मिनल में npm help workspaces ओपन मैनुअल पेज
• npm help workspaces --viewer=browser इसके बजाय एक ब्राउज़र में एक ही डॉक्टर पृष्ठ खोलता है

कार्यक्षेत्रों की मौलिक कार्यक्षमता, निर्भरता स्थापित करने की तरह, काम नहीं करती है: # 2035 और # 1984

जब हम सही सॉफ़्टवेयर बनाने का प्रयास करते हैं, तो कभी-कभी अनपेक्षित बग और / या समायोजन किए जाते हैं और हम अपने साप्ताहिक पैच रिलीज़ में उन समस्याओं से निपटना जारी रखेंगे।

कार्यक्षेत्र की स्थिति क्या है? क्या उन्होंने वास्तव में npm 7 के साथ लॉन्च किया है? और क्या किसी को वास्तव में उन्हें अभी तक कोशिश करनी चाहिए?

[email protected] साथ शिप किए गए कार्यस्थान समर्थन नींव का काम है जो शीर्ष-स्तरीय रूट पैकेज से npm install के संदर्भ में कार्यस्थानों को ठीक से लिंक करता है। जब हमने RFC लिंक को ब्लॉग पोस्ट और अन्य संचार चैनलों से जोड़ने का इरादा चुना था, तो पारदर्शी होना था और तकनीकी दृष्टिकोण से यह स्पष्ट करना था कि किस स्तर पर सहायता प्रदान की जा रही है।

व्यक्तिगत रूप से, कार्यक्षेत्रों के समर्थन को लागू करते समय मेरे मुख्य डिजाइन लक्ष्यों में से एक यह सुनिश्चित करना था कि यह अभी भी एक्स्टेंसिबल है और मौजूदा टूलींग के समृद्ध पारिस्थितिकी तंत्र को पूरा करता है - यह कहा, यदि आपको [email protected] में अधिक सुविधा संपन्न अनुभव की आवश्यकता है अन्य उपकरणों जैसे कि लर्न के साथ इसका उपयोग करना चाहते हैं जो कि npm7 से लाभान्वित करने में सक्षम होने के साथ-साथ कार्यस्थानों के प्रबंधन के आसपास वर्कफ़्लो की एक विस्तृत श्रृंखला प्रदान करेगा। विशेष रूप से Lerna में useWorkspaces कॉन्फ़िगरेशन lerna bootstrap जो इसे सक्षम करना चाहिए ।

हमारे पास एक अनुवर्ती RFC है जो कि npm cli द्वारा बॉक्स से प्रदान की गई सुविधाओं के सेट का विस्तार करता है और आप v7 के भविष्य के सेमी-माइनर रिलीज़ में उस लैंडिंग के लिए नज़र रख सकते हैं।

क्या उनकी स्थिति के बारे में सार्वजनिक डॉक्स में कुछ जोड़ा जा सकता है?

जैसा कि मैंने पहले भी उल्लेख किया है कि वे npm cli के भीतर सार्वजनिक डॉक्स का हिस्सा हैं, लेकिन मैं यह भी समझता हूं कि आप https://docs.npmjs.com/ वेबसाइट का संदर्भ ले सकते हैं। उस मामले में हमारे पास एक टीम है जो जल्द ही इसे प्राप्त करने के लिए काम में कठिन है।

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

धन्यवाद फिर से और कृपया मुझे बताएं कि क्या अभी भी कोई सवाल है! 😄

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

• क्या वर्कस्पेस रूट पर एक एकल package-lock.json होना चाहिए (जैसे कि यार्न 1 करता है), या कार्यक्षेत्र पैकेजों में अलग-अलग लॉकफाइल्स हो सकते हैं (जैसे कि Lerna उन्हें बनाता है)?
• हमें कार्यक्षेत्र के भीतर पैकेजों को कैसे स्थापित / अनइंस्टॉल करना चाहिए? ऐसा लगता है कि ये आदेश कार्यक्षेत्र रूट node_packages फ़ोल्डर से जुड़ी स्थानीय निर्भरता को हल नहीं कर सकते हैं।
  
  
  
  • उदाहरण: कार्यक्षेत्र पैकेज @myworkspace/package-b कार्यक्षेत्र पैकेज @myworkspace/package-a पर निर्भर करता है। मैं हो रही है npm ERR! code ETARGET / npm ERR! notarget No matching version found for @myworkspace/package-a@^1.0.0 में त्रुटियों package-b जब तक कि मैं एक स्थानीय पथ संदर्भ (करने के लिए पैकेज संदर्भ बदल "@myworkspace/package-a": "file:../package-a" )। क्या हम ऐसे स्थानीय पथ संदर्भों का उपयोग करने वाले हैं (जिन्हें तब Lerna की तरह 3 पार्टी टूल की आवश्यकता होती है जो package.json को सेवर नोटेशन डिपो पर प्रकाशित करते हैं)? मूल कार्यक्षेत्र RFC अन्यथा सुझाव देता है।
  
  
  • आप कह रहे हैं कि हम "[[email protected]] का उपयोग करना चाह सकते हैं जैसे कि अन्य उपकरण जैसे कि लार्ना जो कार्यस्थानों के चारों ओर वर्कफ़्लो की एक विस्तृत श्रृंखला प्रदान करेगा"। Lerna के पास add कमांड है जो कार्यक्षेत्र पैकेजों में निर्भरता स्थापित करती है जो package.json स्थानीय सेवर निर्भरता अभिव्यक्तियों वाली npm uninstall का उपयोग करने की आवश्यकता है जो वर्णित मुद्दे पर वापस आती है।
  
  

• क्या वर्कस्पेस रूट पर एक एकल package-lock.json होना चाहिए (जैसे कि यार्न 1 करता है), या कार्यक्षेत्र पैकेजों में अलग-अलग लॉकफाइल्स हो सकते हैं (जैसे कि Lerna उन्हें बनाता है)?

हां, सिर्फ एक package-lock.json be होना चाहिए

• हमें कार्यक्षेत्र के भीतर पैकेजों को कैसे स्थापित / अनइंस्टॉल करना चाहिए? ऐसा लगता है कि ये आदेश कार्यक्षेत्र रूट node_packages फ़ोल्डर से जुड़ी स्थानीय निर्भरता को हल नहीं कर सकते हैं।

[email protected] लिए उन्हें संभालने का सबसे अच्छा तरीका मैन्युअल रूप से package.json प्रत्येक बाल कार्यक्षेत्र के लिए संपादन करना और npm install को शीर्ष-स्तर से चलाना है।

• उदाहरण: कार्यक्षेत्र पैकेज @myworkspace/package-b कार्यक्षेत्र पैकेज @myworkspace/package-a पर निर्भर करता है। मैं हो रही है npm ERR! code ETARGET / npm ERR! notarget No matching version found for @myworkspace/package-a@^1.0.0 में त्रुटियों package-b जब तक कि मैं एक स्थानीय पथ संदर्भ के लिए पैकेज संदर्भ बदल ( "@myworkspace/package-a": "file:../package-a" )। क्या हम ऐसे स्थानीय पथ संदर्भों का उपयोग करने वाले हैं (जो तब लर्न की तरह 3 पार्टी उपकरणों की आवश्यकता होती है जो package.json को सेवर नोटेशन डिप्स पर प्रकाशित करते हैं)? मूल कार्यक्षेत्र RFC अन्यथा सुझाव देता है।

हम्म specific एक कानूनी बग हो सकता है - आपके विशिष्ट उदाहरण से यह मान्य करना अच्छा होगा कि दोनों @myworkspace/package-b और @myworkspace/package-a ठीक से परिभाषित / आपके package.json "workspaces" package.json "workspaces" से / खोज योग्य हैं नहीं है file:./<location> semver रेंज आप का उल्लेख के रूप में, इतनी के रूप में है कि डीईएफ़ के नहीं मामला। 😊

• आप कह रहे हैं कि हम "[[email protected]] का उपयोग करना चाह सकते हैं जैसे कि अन्य उपकरण जैसे कि लार्ना जो कार्यस्थानों के चारों ओर वर्कफ़्लो की एक विस्तृत श्रृंखला प्रदान करेगा"। Lerna के पास add कमांड है जो कार्यक्षेत्र पैकेजों में निर्भरता स्थापित करता है जो package.json स्थानीय सेवर निर्भरता अभिव्यक्तियों वाली npm uninstall का उपयोग करने की आवश्यकता है जो वर्णित मुद्दे पर वापस आती है।

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

प्रतिक्रिया @ruyadorno के लिए धन्यवाद। मेरा मतलब यह नहीं था कि मुझे लगता है कि npm को सही सॉफ्टवेयर बनाना चाहिए। मैं वास्तव में बता सकता हूं कि डॉक्स साइट से फीचर की स्थिति क्या है, इसकी अनुपस्थिति दी गई थी, और इसे स्थापित करने में मेरी असमर्थता थी। मैं npm help जांच करूंगा और वेबसाइट पर 7.x डॉक्स का इंतजार करूंगा। मैं कार्यक्षमता के लिए विशिष्ट मुद्दों का पालन करूंगा।

btw नए डॉक्स ऊपर हैं d https://docs.npmjs.com/cli/v7/use-npm/workspaces - धन्यवाद @ethomson are

"नोहिस्ट" का समर्थन करने की कोई योजना? प्रतिक्रिया-मूलक कार्य के लिए आवश्यक

hi @ acates-happymoney मुझे लगता है कि बेहतर हो सकता है कि एक अलग मुद्दे पर नज़र रखना बेहतर होगा, अगर आप एक प्रजनन मामला प्रदान कर सकें, ताकि हमारे लिए यह जानना आसान हो जाए कि इस पर कैसे कार्य किया जाए happ

एक उदाहरण के रूप _yarn_ का उपयोग के संबंध में के खिलाफ विपरीत noHoist । कार्यस्थान सुविधा का उपयोग करते हुए, _yarn_ आपके पैकेज में _node_modules_ निर्देशिकाओं पर निर्भरता नहीं जोड़ता है - केवल रूट स्तर पर, अर्थात, _yarn_ सभी निर्भरताएँ रूट स्तर तक लहराता है। _yarn_ विभिन्न पैकेजों की ओर संकेत करने के लिए सीलिंक का लाभ उठाता है। जिससे _yarn_ परियोजना में केवल एक बार निर्भरता शामिल है। ध्यान दें, यह _npm_ के साथ सममूल्य पर है।

मोनोरेपो वातावरण में काम करने वाले अन्यथा असंगत 3 पार्टी निर्भरता का उपयोग करने के लिए आपको _yarn कार्यस्थान_ ' noHoist सुविधा का उपयोग करना होगा। आपको इसे प्रोजेक्ट रूट _package.json_ में निर्दिष्ट करना होगा। अधिक जानकारी के लिए ConnectDotz के डेमो प्रोजेक्ट पर एक नज़र डालें।

किसी भी घटना में, त्वरित प्रतिक्रिया के लिए अग्रिम धन्यवाद। ऐसा लगता है कि यह जल्द ही कभी भी अभ्यस्त नहीं होगा, इसलिए इसका उत्तर मुझे ढूंढना था !! चीयर्स और महान काम npm7 पर।