هل طلب الميزة الخاص بك متعلق بمشكلة؟
لقد واجهتنا بعض المشكلات حيث يفشل النشر نظرًا لنشر إصدار معين بالفعل. هذه ليست عملية عادية يجب أن يحدثها الإصدار التلقائي ... لكنها تحدث. كان لدينا خطأ الليلة الماضية وقرر شخص ما النشر يدويًا إلى npm دون الاصطدام بإصدار package.json. تسبب ذلك في وصول كل شيء إلى حالة سيئة لم يتم حلها حتى صدمنا الإصدار يدويًا.
صِف الحل الذي تريده
استمر في تحديث الحقل version
في package.json ، لكن استخدم إصدار npm كمصدر للحقيقة. أعط تحذيرًا إذا كان هناك خطأ مطابق ، ولكن قم بتحديث الإصدار استنادًا إلى الإصدار الموجود على npm ، وليس الإصدار الموجود في package.json.
ووه أنا أحب ذلك. قد يكون هذا صعبًا بالنسبة إلى monorepos بالرغم من ذلك
نظرًا لأننا نقوم باستخدام --force-publish=*
لـ lerna ، فلن تكون هناك مشكلة نظرًا لأن جميع الحزم يجب أن تحتوي على إصدار مرتبط.
إذا أزلنا هذا العلم في المستقبل ، فسنضطر إلى ... عدم الاكتراث
أيضًا قمنا بتشغيل npm version
والذي يأخذ فقط سلسلة semver. لا نقوم بالفعل بتعيين رقم حزمة في أي مكان في الوقت الحالي. لن يكون من الصعب ضبطها بأنفسنا ولكن يبدو أن monorepos مرة أخرى لن تكون بسيطة
تعمل معظم الأوامر على العلامات أيضًا ، لذا إذا لم يتم وضع علامة على الإصدار ، فقد يتسبب ذلك في بعض المشكلات.
"أنا مقتنع بشكل متزايد أن وضع الإصدار" المستقل "كان خطأ. كل ما يفعله هو جعل الأشخاص يرمون حزمًا عشوائية في مستودع واحد ثم يشتكون عندما يتعين عليهم إصدارها في نفس الوقت." ~ من مشرف lerna.
لذا يبدو --force-publish=*
جيدًا.
--force-publish
والإصدارات المستقلة ليستا نفس الشيء.
بشكل افتراضي ، لن تنشر lerna سوى تحديث لحزمة إذا كانت بها تغييرات عليها ، باستخدام --force-publish=*
نجبر lerna على نشر نسخة من جميع الحزم حتى لو لم تكن هناك تغييرات منذ آخر عملية نشر.
أي الحزمة A
بها تغييرات ، و B
لا تتغير. ستقوم lerna بنشر إصدار جديد فقط من A
(سيبقى B
في نسخته الحالية). تم تغيير الإصدار التالي A
و B
، وسيتم نشرهما بنفس الإصدار الجديد.
هناك شيء كنت أفكر فيه (ولست متأكدًا مما إذا كان هذا شيئًا ندعمه على الإطلاق) هو إمكانية الإصدارات التي ليست master
(أو الفرع الرئيسي). حتى هذه النقطة ، افترضنا دائمًا أن هناك مسارًا واحدًا للإصدارات - وهي دائمًا خطية (باستخدام الإصدار latest
على npm أو github).
ماذا يحدث في حالة الحاجة إلى تصحيح إصدار سابق؟ (1.x به خطأ ، master
موجود على 2.x لكنك تريد تصحيح 1.xw / إصلاح أيضًا) إذا كنا سنخرج من lerna
أو pkg
إصدار
إذا غيرنا هذا لاستخدام شيء ما خارج شجرة git ، فلا أعتقد أننا سنكون قادرين على دعم هذا السلوك ، حيث لا يوجد سوى 1 latest
على npm (أو في أي مكان نحضر فيه أحدث إصدار)
هذا يبدو وكأنه ميزة جيدة. قد يستغرق الأمر بعض العمل للتنفيذ.
إصدار:
version
باستخدام أحدث إصدار - هل يمكن أن يتحول هذا بسهولة إلى إصدار الحزمة؟الافراج / سجل التغيير
getCurrentVersion
lastRelease if gt (lastRelease ، lastVersion) - لذلك يجب أن يكون هذا على علم بذلك أيضًاهذا يعني أننا نستخدم بالفعل أشياء خارج شجرة git ، أليس كذلك؟
نحتاج إلى الاعتماد على أحدث إصدار للتأكد من أنه يحتوي على علامة git مرتبطة به ، لذا فإن التبديل ليس خيارًا لأننا لا نستطيع التأكد من أن أحدث إصدار npm يحتوي على علامة (كما هو الحال في الشيء الذي توضحه هذه المشكلة) .
أعتقد أننا سنحتاج على الأرجح إلى علامة جديدة من إصدارات علامة git الأخيرة. --from-git
مع ذلك من المحتمل أن يعمل أمر الإصدار. سيتعين علينا ترتيب شكل التغيير.
يمكن أن يتجاوز العلم --from-git
أيضًا النظر إلى NPM لأي شيء. أعتقد أن هذا يعني أنه يمكننا دمج # 173
التعليق الأكثر فائدة
نحتاج إلى الاعتماد على أحدث إصدار للتأكد من أنه يحتوي على علامة git مرتبطة به ، لذا فإن التبديل ليس خيارًا لأننا لا نستطيع التأكد من أن أحدث إصدار npm يحتوي على علامة (كما هو الحال في الشيء الذي توضحه هذه المشكلة) .
أعتقد أننا سنحتاج على الأرجح إلى علامة جديدة من إصدارات علامة git الأخيرة.
--from-git
مع ذلك من المحتمل أن يعمل أمر الإصدار. سيتعين علينا ترتيب شكل التغيير.
يمكن أن يتجاوز العلم
--from-git
أيضًا النظر إلى NPM لأي شيء. أعتقد أن هذا يعني أنه يمكننا دمج # 173