Auto: सत्य के संस्करण स्रोत के रूप में npm का प्रयोग करें

ऊह मुझे वह पसंद है। हालांकि मोनोरेपो के लिए यह मुश्किल हो सकता है

चूंकि हम लर्न के लिए --force-publish=* करते हैं, इसलिए यह कोई समस्या नहीं होनी चाहिए क्योंकि सभी पैकेजों में एक लिंक्ड संस्करण होना चाहिए।

भविष्य में अगर हम उस झंडे को हटा दें तो हमें... idk

इसके अलावा हम सिर्फ npm version चलाते हैं जो केवल एक सेवर स्ट्रिंग लेता है। हम वास्तव में अभी कहीं भी पैकेज संख्या निर्धारित नहीं करते हैं। इसे स्वयं सेट करना कठिन नहीं होगा, लेकिन मोनोरपॉज़ फिर से ऐसा प्रतीत होता है कि वे सरल नहीं होंगे

अधिकांश कमांड टैग पर भी काम करते हैं, इसलिए यदि रिलीज को टैग नहीं किया गया तो इससे कुछ समस्याएं हो सकती हैं।

https://github.com/azu/can-npm-publish

"मैं तेजी से आश्वस्त हूं कि" स्वतंत्र "संस्करण मोड एक गलती थी। यह केवल लोगों को एक ही भंडार में यादृच्छिक पैकेज फेंक देता है और फिर शिकायत करता है कि उन्हें एक ही समय में उन्हें संस्करण देना है।" ~ लर्न मेंटेनर से।

तो --force-publish=* ठीक लगता है।

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

यानी पैकेज A इसमें बदलाव हैं, B में नहीं। लर्न केवल A का एक नया संस्करण प्रकाशित करेगा ( B अपने वर्तमान संस्करण पर रहेगा)। अगली रिलीज़ A और B में परिवर्तन हैं, वे दोनों एक ही नए संस्करण के साथ प्रकाशित होंगे।

मैं जिस चीज के बारे में सोच रहा था (और मुझे यकीन नहीं है कि अगर यह कभी ऐसी चीज है जिसका हम समर्थन करेंगे) तो ऐसे रिलीज की संभावना है जो master (या मुख्य शाखा) नहीं हैं। इस बिंदु तक, हमने हमेशा माना है कि रिलीज के लिए 1 पथ है - और वे हमेशा रैखिक होते हैं (एनपीएम या जीथब पर latest संस्करण का उपयोग करके)।

पिछली रिलीज़ को पैच करने की आवश्यकता के मामले में क्या होता है? (1.x में एक बग है, master 2.x पर है लेकिन आप 1.xw/एक फिक्स भी पैच करना चाहते हैं) अगर हम lerna या pkg दूर जा रहे हैं

अगर हम इसे गिट ट्री के बाहर कुछ उपयोग करने के लिए बदलते हैं तो मुझे नहीं लगता कि हम उस व्यवहार का समर्थन करने में सक्षम होंगे, क्योंकि एनपीएम पर केवल 1 latest है (या जहां से हम नवीनतम संस्करण प्राप्त करते हैं)

यह एक अच्छी सुविधा की तरह लगता है। इसे लागू करने में कुछ काम लग सकता है।

संस्करण:

• हम नवीनतम रिलीज़ का उपयोग करके version गणना करते हैं - क्या यह आसानी से पैकेज संस्करण में बदल सकता है?
• जीथब पर नवीनतम रिलीज एक समस्या हो सकती है। मुझे नहीं लगता कि आप वास्तव में "नवीनतम रिलीज" प्रोग्रामेटिक रूप से सेट कर सकते हैं। इसलिए 1.x पर पैच प्रकाशित करते समय यह नवीनतम रिलीज़ बन जाएगा।

रिलीज/चेंजलॉग

• getCurrentVersion अगर gt(lastRelease, lastVersion) अंतिम रिलीज देता है - तो इसके बारे में भी पता होना चाहिए

इसका मतलब है कि हम पहले से ही गिट ट्री के बाहर सामान का उपयोग कर रहे हैं, है ना?

हमें यह सुनिश्चित करने के लिए नवीनतम रिलीज़ पर निर्भर रहने की आवश्यकता है कि इसके साथ एक git टैग जुड़ा हुआ है, इसलिए स्विचिंग एक विकल्प नहीं है क्योंकि हम यह सुनिश्चित नहीं कर सकते हैं कि नवीनतम npm संस्करण में एक टैग है (जैसे कि इस मुद्दे में वर्णित है) .

मुझे लगता है कि हमें शायद एक नए ध्वज की आवश्यकता होगी जो पिछले गिट टैग से संस्करण हो। --from-git

इसके साथ रिलीज कमांड शायद काम करेगा। हमें यह पता लगाना होगा कि चैंज कैसा दिखता है।

--from-git ध्वज किसी भी चीज़ के लिए NPM को देखने से भी आगे निकल सकता है। मुझे लगता है कि इसका मतलब है कि हम #173 . का विलय कर सकते हैं