Auto: لا يصطدم المكون الإضافي npm بالإصدار package.json

هذا حسب التصميم. إذا تم الالتزام بالإصدار ، فقد يؤدي ذلك إلى دمج تعارضات عند الدمج في الإصدار الرئيسي. هناك علامة git تم إنشاؤها بالرغم من ذلك

هذه القضية تؤثر عليّ أيضًا.

هذا حسب التصميم. إذا تم الالتزام بالإصدار ، فقد يؤدي ذلك إلى دمج تعارضات عند الدمج في الإصدار الرئيسي. هناك علامة git تم إنشاؤها بالرغم من ذلك

ما هي الطريقة الموصى بها لضمان بقاء إصدارات package.json متزامنة مع عمليات نشر CI باستخدام auto shipit ؟

لست متأكدًا من أنني أفهم تمامًا حالة الاستخدام @ smithki. حالة استخدام thuringia منطقية ، فهو يحتاج إلى الإصدار لتحديث أشياء أخرى ، لكنني متردد جدًا في تغيير السلوك. هل يمكنك تفصيل ما تحاول تحقيقه؟

آسف ، قد يكون لدي سوء فهم. من صياغة المشكلة ، أظن أن الفروع next لا تتلقى إصدارات محدّثة من package.json ، لكن الفروع main تفعل ذلك (لا تزال تتعلم auto إجمالي المبتدئين هنا) . حالة الاستخدام الخاصة بي هي نفسها كما في الإصدار الأصلي ، ولكن لكي أكون محددًا:

أحتاج إلى قراءة الإصدار package.json في وقت _build_ لمكتبة NPM بحيث يمكن إدخال الإصدار الحالي package.json كمتغير بيئة. هذا يعني أنني بحاجة إلى إصدار ملفات package.json قبل تشغيل الإصدار. ببساطة استيراد package.json لا يعمل بشكل جيد مع إعداد TypeScript الحالي ، والذي يعتمد على rootDirs في tsconfig.json (و package.json غير مضمن في rootDirs ، وبالتالي خطأ في المترجم ، وبالتالي الحاجة إلى متغير بيئة).

هل يمكنك أن تفعل ما يفعله auto ؟ https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L306 -L310

سأرى ما إذا كان بإمكاني حلها ، وليس في نيتي إخراج الموضوع الأصلي لهذه المشكلة عن مساره.

هل يمكنك أن تفعل ما تفعله السيارة؟ https://github.com/intuit/auto/blob/master/packages/core/src/auto.ts#L306 -L310

للأسف لا ، لأن الكود مخصص ليتم تشغيله من جانب العميل (سأفتح مشكلة جديدة إذا لم أجد حلًا بديلًا).

آه ، تصويت آخر لي لإصلاح سلوك التشغيل الجاف عاجلاً وليس آجلاً. سنلقي نظرة على إصلاح كل ذلك في نهاية الأسبوع المقبل. شكرًا لك على التعليقات واستخدام auto !

hipstersmoothie شكرا على الرد السريع :) أنت دائما تفاجئني

لقد وجدت حلاً قويًا جدًا في الوقت الحالي ، auto shipit --dry-run --plugins git-tag . هذا في الواقع منطقي للغاية على أي حال للتحقق من الإصدار التالي بهذه الطريقة للإصدارات المسبقة.
شكرًا لأخذ لقطة في تحسينات التشغيل التجريبي قريبًا. إذا كان هناك مبنى كناري تريد تجربته ، فأخبرني بذلك. سأكون سعيدا للمساعدة.

على أي حال ، شكرًا جزيلاً على auto ! جعلت حياتي أسهل بكثير

thuringiasmithki هل يمكنك اختبار ومعرفة ما إذا كان 10 يحل مشاكلك ؟

hipstersmoothie هذا يعمل بشكل جيد في الإصدار 10 👍
إنه أبطأ بشكل ملحوظ ، أو بالأحرى يستغرق وقتًا طويلاً مثل تشغيل shipit بدون --dry-run .

شكرا لإخراج هذا بسرعة!

لست متأكدًا مما إذا كان هذا خطأ أم لا:
عندما قمت بترقية الحزم باستخدام yarn add -D auto@next ، اختفت التغييرات إلى package.json و yarn.lock بعد تشغيل auto shipit --dry-run . كان الإصدار v10 لا يزال موجودًا في node_modules لذا يبدو أنه تمت إعادة تعيين دليل العمل.

على الرغم من أنه أبطأ بشكل ملحوظ ، أو بالأحرى يستغرق وقتًا طويلاً مثل تشغيل السفينة دون الجفاف.

سأرى ما إذا كان بإمكاني تحسين ذلك. ولكن نظرًا لأننا ندعو المكوّن الإضافي الآن ، فإنه يقوم بالكثير من العمل لطباعة الإصدارات التالية الحقيقية.

اختفت التغييرات التي تم إجراؤها على package.json و yarn.lock بعد تشغيل auto shipit --dry-run

آه هذا خطأ. بالنسبة للتشغيل الجاف ، تخطيت الفحص النظيف ولكني لم أتخطى إعادة تعيين البوابة

thuringia ما نوع المشروع الذي

hipstersmoothie أنا بخير تمامًا مع التباطؤ في التشغيل الجاف الآن. إنه ليس بهذا الاختلاف الكبير. قصدته في الغالب كملاحظة أنك تشعر بالتغيير ، ربما كان يجب علي إضافة رمز تعبيري هناك 😄
على الرغم من ذلك ، نرحب دائمًا بأي تعزيز للأداء.

في هذه الحالة ، إنه مشروع مختلط يتكون في الغالب من تطبيق Java مع بعض lambdas حوله. لإنشاء إصدار ، يجب أن:

• قم بتشغيل gradle لبناء الجرة برقم الإصدار
• حزمة تلك الجرة في صورة عامل ميناء ، ووضع علامة عليها ونشرها
• نشر lambdas باستخدام إطار عمل بدون خادم يستخدم رقم الإصدار لوضع العلامات وتكوين الحاويات

ليست حالة استخدام افتراضية لـ auto 😂
عادةً ما أستخدمه لمشاريع Node أو React ذات الإعدادات الأكثر انسيابية ، لكنني لم أحتاج مطلقًا إلى الحصول على رقم إصدار قبل نشر الإصدار بالفعل مثلما أحتاج لهذا المشروع المعين

: صاروخ: تم إصدار الإصدار في v10.0.0 : صاروخ: