Auto: ملحقات متعددة لمدير الحزم في 1 ريبو

تم إنشاؤها على ٢٨ يناير ٢٠٢٠ · 16تعليقات · مصدر: intuit/auto

هل طلب الميزة الخاص بك متعلق بمشكلة؟

في الوقت الحالي ، يمكنك فقط استخدام مكون إضافي واحد لمدير الحزم لكل مشروع. هذا يعني أنه لا يمكنك استخدام المكوّن الإضافي chrome-web-store المكوّن الإضافي npm في الريبو الواحد.

صِف الحل الذي تريده

هذا القيد يرجع أساسًا إلى أن auto يعمل حاليًا على أساس مشروع git وليس له مفهوم الحزمة.

في المكون الإضافي npm ، لقد أوضحت كيف يمكنك إدارة التغيير والإصدارات المنفصلة مقابل sub-packages . يعتمد كل هذا على حوالي lerna ولا يمكن نقله إلى core .

ولكن نظرًا لأن كل مكون إضافي لمدير الحزم يعتمد على بعض الملفات الإضافية لمدير الحزم (جميعها باستثناء git-tag ) يمكننا بسهولة القيام بشيء مثل:

مثال: npm plugin

عند تحميله يحاول العثور على package.json (مفرد أو lerna)
auto أي شيء في هذا المجلد جزءًا من package
يدير auto سجل تغيير فريدًا لكل package

قد تكون هذه تجربة سيئة. بدلاً من ذلك ، يمكننا فقط إضافة خيار تكوين إضافي لجميع مكونات مدير الحزم لمجلد. يمكن أن يدعم هذا أيضًا المكون الإضافي git-tg (وستكون هناك حاجة لجعله يعمل على الإطلاق).

المشاكل المحتملة

يقوم كل مكون إضافي حاليًا بالالتزام والعلامات والدفع. هذا من شأنه أن يخلق الكثير من الضوضاء. من المحتمل أن تضطر إلى نقل إجراءات git هذه إلى الجوهر بحيث تحدث مرة واحدة فقط؟ على الرغم من أنك قد ترغب في التزامات منفصلة لكل package .
التغيير الجذري - ربما لن يكون له معنى في هذا النوع من المشاريع. سيؤدي كل مكون إضافي لمدير الحزم أيضًا إلى إنشاء سجل تغيير لكل package مُدار

صِف البدائل التي فكرت فيها

لا شيئا حقا.

enhancement

مصدر

hipstersmoothie

ال 16 كومينتر

بالتفكير في الأمر أكثر من ذلك بقليل ، ربما يكون من المنطقي تقديم خيار تكوين مستوى أعلى جديد.

{
  // Still have some global config at root
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  // Plugins used for every package
  "plugins": ["conventional-commits"],
  "packages": [
    // Target specific directories and apply a set of plugins to them
    {
      "target": "www",
      "plugins": ["git-tag"]
    },
    {
      "target": "api",
      "plugins": ["npm"]
    },
    // Specify a pattern or even and array of patterns or directories
    {
      "target": ["packages/**",  "utils"],
      "plugins": ["npm"]
    },
    {
      "target": "web-store",
      "plugins": [
        "chrome-web-store",
        // Whole lifecycle is run for each package so you can have package plugins
        ["upload-assets", { "assets": ["./path/to/file"] }]
      ]
    }
  ]
}

لتحقيق ذلك ، أعتقد أنه يمكننا استخدام وظائف المكرر لتشغيل shipit على أشياء متعددة وتوليد نفس القدر من الارتباطات

السابق لأحدث:

تشغيل الكل في نفس الوقت
العائد قبل ارتكاب التغيير
ارتكاب التغيير دفعة واحدة
العائد حتى صدم الإصدار
إصدار الالتزام إذا لزم الأمر
تشغيل حتى النهاية

hipstersmoothie في ٢٨ يناير ٢٠٢٠

مع هذا الإعداد ، يمكنك حقًا تخطي lerna معًا

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    }
  ]
}

إذا لم تتم مطابقة أي التزامات مع package فلن يتم إصدار أي تحرير. هذا يحقق إدارة monorepo مستقلة بطريقة أبسط بكثير وبدون lerna . إذا كنت تريد نسخة ثابتة monorepo فإن المسار الكلاسيكي سيكون هو الطريق.

ميزة أخرى رائعة لهذا هو أنه يمكن أن يكون لديك مشروعين leran في الريبو الخاص بك مع مخططات إصدار مختلفة ( fixed و independent )

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "fixed-monorepo",
      "plugins": ["npm"]
    },
    {
      "target": "independent-monorepo",
      "plugins": ["npm"]
    }
  ]
}

hipstersmoothie في ٢٨ يناير ٢٠٢٠

هذا يعني أنه يمكنك استخدام المكوّن الإضافي chrome-web-store المكوّن الإضافي npm في ريبو واحد.

أفترض أنك تعني أنك لا تستطيع استخدام كليهما في نفس المشروع؟

يقوم كل مكون إضافي حاليًا بالالتزام والعلامات والدفع. هذا من شأنه أن يخلق الكثير من الضوضاء. من المحتمل أن تضطر إلى نقل إجراءات git هذه إلى الجوهر بحيث تحدث مرة واحدة فقط؟ على الرغم من أنك قد ترغب في التزامات منفصلة لكل حزمة.

قد يكون من المنطقي القيام بنهج هجين. ربما يلتزم كل مكون إضافي ، لكننا ندفع مرة واحدة فقط؟

لست متأكدًا حقًا من كيفية عمل العلامات في العالم حيث يكون كل مجلد عبارة عن إصدار حزمة خاص به. هل تنشئ علامة لكل إصدار تقوم بإنشائه؟ هل تصنع واحدة في النهاية؟

بالتفكير في الأمر أكثر من ذلك بقليل ، ربما يكون من المنطقي تقديم خيار تكوين مستوى أعلى جديد.

تعجبني فكرة القدرة على تخصيص تجربة الإصدار لكل حزمة. يمكن بالتأكيد رؤية بعض فوائد القدرة على إدارة نشر s3 / gh-pages لحزمة docs مقابل حزم مكتبتك.

هناك شيء واحد يجب التعامل معه وهو تضمين حزمة في أكثر من خط أنابيب تحرير واحد. ماذا يحدث في حالة:

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": ["npm"]
    },
    {
      "target": "packages/chrome-ext",
      "plugins": ["chrome-web-store"]
    },
  ]
}

هل يتم نشر الحزمة chrome-ext لكل من npm _ و_ webstore ؟ أم أن الإصدار npm يفوز لأنه تم الإعلان عنه أولاً؟

adierkens في ٢٨ يناير ٢٠٢٠

لست متأكدًا حقًا من كيفية عمل العلامات في العالم حيث يكون كل مجلد عبارة عن إصدار حزمة خاص به. هل تنشئ علامة لكل إصدار تقوم بإنشائه؟ هل تصنع واحدة في النهاية؟

أعتقد أنه يمكننا مضاهاة سلوك lerna. فقط الكثير من العلامات على التزام واحد. ثم تصبح كل علامة إصدارها الخاص

hipstersmoothie في ٢٨ يناير ٢٠٢٠

👍1

هل يتم نشر حزمة chrome-ext على كل من npm و webstore؟ أم أن إصدار npm يفوز لأنه تم الإعلان عنه أولاً؟

في هذه الحالة ، نعم ، سيحاول القيام بالأمرين معًا. لكن هذا مجرد تكوين سيء. يمكنك استخدام ذلك كميزة والقول نشر حزمة إلى سجلين مختلفين (على سبيل المثال: npm و github package Registry)

{
  "name": "Andrew Lisowski",
  "email": "[email protected]",
  "packages": [
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://npm" }]]
    },
    {
      "target": "packages/**",
      "plugins": [["npm", { registry: "https://github-package-registry" }]]
    },
  ]
}

hipstersmoothie في ٢٨ يناير ٢٠٢٠

❤1

هذا يبدو مثيرا للاهتمام ... ومعقدا 😅

أنا بشكل عام 👍 مع وجود تكوين أكثر من محاولة أن أكون ذكيًا للغاية في الاكتشاف (لأن ذلك يمكن أن ينهار بطرق غير متوقعة ويصعب اختباره).

أعتقد أن سؤالي الأول هو كيف تبدو الحالة الافتراضية لهذا. إذا كان لديك مكون إضافي npm ، فهل تحتاج إلى إضافة التكوين قبل أن يعمل؟ نفس السؤال مع الآخرين.

بالنسبة لتفاعل git ، يبدو لي أن تفاعلات git يجب أن تكون بشكل عام جزءًا من خط أنابيب البرنامج المساعد. إذا احتاج المكون الإضافي إلى إجراء التزام ، فيجب أن يكون قادرًا على النقر على خطاف قابل للالتزام. من المحتمل أن يتم التعامل مع الدفع فقط في جوهره على الرغم من أنه له آثار على أشياء مثل كيفية عمل CI.

zephraph في ٢٨ يناير ٢٠٢٠

إذا كان لديك مكون إضافي npm ، فهل تحتاج إلى إضافة التكوين قبل أن يعمل؟

يجب أن يعمل التكوين الذي يعمل اليوم في packages world. لذلك لا يلزم إجراء تغييرات. ستكون معظم التغييرات الفاصلة هي جانب واجهة برمجة تطبيقات العقدة ولن تكون مرئية للمستخدمين العاديين.

إذا احتاج المكون الإضافي إلى إجراء التزام ، فيجب أن يكون قادرًا على النقر على خطاف قابل للالتزام.

اعجبتني هذه الفكرة. من المحتمل أن يكون إضفاء الطابع الرسمي على تفاعل git داخل auto مفيدًا. وإذا لم يستخدموا هذا الخطاف ، فهذا يعني فقط المزيد من الضوضاء (على سبيل المثال: التزام إضافي ودفع إضافي)

hipstersmoothie في ٢٨ يناير ٢٠٢٠

كنت أفكر أيضًا في كيفية استخدام Auto مع monorepo وتوصلت إلى نهج مختلف قليلاً قد يناسب احتياجاتك.

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

يمكنك بعد ذلك اختيار بادئة مختلفة لكل مشروع بحيث يمكن إصدار كل مشروع في أوقات مختلفة إذا لزم الأمر. على سبيل المثال ، يمكن وضع علامة على إصدار مشروع فرعي sub-project/v1.4.5 وسيحصل مشروع آخر على العلامة sub-project2/v9.9.9

يمكن لـ Auto بعد ذلك استخدام شيء مثل git describe --tags --matches "sub-project1/*" للحصول على العلامات وتحديثها لكل مشروع وفقًا لذلك.

مجرد فكرة.

barreeyentos في ٣٠ يناير ٢٠٢٠

👍1

هذا في الواقع قريب جدًا من النهج الذي كنت أتبعه. لقد قمت
كنت أعمل عليها هذا الأسبوع.

اضطررت إلى إضافة هذه العلامة إلى بعض الأوامر حتى الآن (- التطابقات) و
كانت تسير بسلاسة تامة.

لقد اتبعت نهج "الحزم" الميداني وهو أساسًا عادل و
مجموعة من "autorc"

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

يوم الأربعاء 29 يناير 2020 الساعة 9:11 مساءً أليخاندرو باريينتوس <
[email protected]> كتب:

كنت أفكر أيضًا في كيفية استخدام Auto مع monorepo وتوصلت إلى
نهج مختلف قليلاً قد يعمل على حاجتك.
في الأساس ، إذا كان لديك monorepo واحد ، يمكنك الحصول على عدة أدلة فرعية
أن لكل منها ملف .autorc الخاص به والذي يمكنه إعداد أي مكونات إضافية
سيحتاج كل مشروع فرعي.
يمكنك بعد ذلك اختيار أن يكون لديك بادئة مختلفة لكل مشروع بحيث
يمكن إطلاق كل مشروع في أوقات مختلفة إذا لزم الأمر. على سبيل المثال أ
يمكن تمييز إصدار المشروع الفرعي 1 بالمشروع الفرعي / v1.4.5 و
مشروع آخر سيحصل على العلامة sub-project2 / v9.9.9
يمكن أن يستخدم Auto بعد ذلك شيئًا مثل git وصف - العلامات - التطابقات
"sub-project1 / *" للحصول على العلامات وتحديثها لكل مشروع وفقًا لذلك.
مجرد فكرة.
-
أنت تتلقى هذا لأنك قمت بتأليف الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/intuit/auto/issues/917؟
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAJDEBDX72NB5Z7ZJPTDHVLRAJOOXANCNFSM4KMLWYFQ
.

hipstersmoothie في ٣٠ يناير ٢٠٢٠

🎉1

بالعودة إلى الوراء وقراءة هذا مرة أخرى ، أنا متحمس جدًا حقًا! تبدو العلامات المتعددة مسبوقة باسم الحزمة جيدة حقًا. أيضًا ، يعجبني حقًا حقل packages .

zephraph في ١ مايو ٢٠٢٠

hipstersmoothie هل هناك طريقة سهلة اليوم للنشر إلى سجلات 2 npm مع shipit ، التي رأيتها؟ أو تبديل بعض الميزات في الوضع التلقائي ليس لدي نظرة عامة جيدة عليها في الوقت الحالي.

vincentbriglia في ١٨ أغسطس ٢٠٢٠

vincentbriglia هل سيعمل المكون الإضافي الذي ينشر على حزمة GitHub؟ يمكن أن يكون إلى حد كبير على ظهره من البرنامج المساعد npm. سيكون من السهل إصدار next و latest ، لكن الكناري ليس له معنى كبير. أفكار؟

hipstersmoothie في ١٨ أغسطس ٢٠٢٠

hipstersmoothie لدينا حالة ننشر فيها نفس الحزمة إلى سجل NPM وسجل GHPR. السبب هنا هو أن GHPR ، على الرغم من الإعلان عنه على هذا النحو ، لا يقوم بتوكيل الحزم بشكل صحيح. المشكلة الأساسية هي أن لدينا نفس النطاق على npm و github.

نحن نطور بشكل أساسي خلف الأبواب المغلقة ، ونستخدم تصميمات الكناري لإجراء محادثات / موافقات مع فريق التصميم لدينا من feature branches > next لذلك لا تزال تصميمات الكناري مفيدة لنا في هذا السياق. يوفر المكون الإضافي npm حاليًا هذه الوظيفة ، لذا سيكون من العار أن تفقدها.

أفترض أن السياق باستخدام GHPR هو بشكل عام أنه الموقع الأساسي للنشر في سياق "المؤسسة" الخاص وإذا كان أحد المكونات سيتم جعله عامًا ، فإن npmjs.org يكون ثانويًا. (لم أر أي شخص يقوم بتثبيت مكونات عامة من جيثب). في سياق المصدر المفتوح ، يكون بشكل عام npmjs ، ولا يوجد GHPR أو سجل حزمة خاص آخر.

في ملاحظة جانبية ، نظرًا لأنك ذكرت مكوّنًا إضافيًا لـ GHPR: لقد خصصنا بعض الوقت للأسبوع المقبل لإنشاء مكون إضافي تلقائي من شأنه إزالة إصدارات الحزمة بناءً على بعض القواعد (تقتصر المؤسسات على 50 جيجا بايت من الحزم ، وهذا يتضمن عامل الإرساء الصور)

إزالة الكناري الأخير في النطاق
إزالة ن آخر التالي في النطاق
...

يسعدني أيضًا أن أنتظر منك إنشاء ناشر ghpr معين حتى يبدأ العمل في الإصدار 10 ، تبدو الأفكار المقدمة هنا مثيرة للغاية وربما تكون "دليلًا مستقبليًا".

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

vincentbriglia في ١٨ أغسطس ٢٠٢٠

كنت أفكر أكثر في المكوّن الإضافي "سجل الحزمة الثانوية". لذلك سيعمل المكون الإضافي npm كما هو ، وينشر على أي سجل تم تكوينه. بعد ذلك ، سيتم نشر هذا المكون الإضافي الجديد في سجل ثانٍ (سواء كان ذلك npm أو ghpr لا يهم) لإصدار أي إصدارات موجودة في HEAD.

في ملاحظة جانبية ، نظرًا لأنك ذكرت مكوّنًا إضافيًا لـ GHPR: لقد خصصنا بعض الوقت للأسبوع المقبل لإنشاء مكون إضافي تلقائي من شأنه إزالة إصدارات الحزمة بناءً على بعض القواعد (تقتصر المؤسسات على 50 جيجا بايت من الحزم ، وهذا يتضمن عامل الإرساء الصور)

هذا يبدو وكأنه ميزة جيدة. لم أكن أعرف أن تلك الحدود موجودة!

hipstersmoothie في ١٨ أغسطس ٢٠٢٠

سيتم نشر هذا المكون الإضافي الجديد في سجل ثانٍ (سواء كان ذلك npm أو ghpr لا يهم) مع إطلاق أي إصدارات موجودة في HEAD

حسنا هذا بالتأكيد سيعمل! تحرير: أيضا لسيناريو لدينا

vincentbriglia في ١٨ أغسطس ٢٠٢٠

أهلا! ما هي الحالة الحالية لـ Auto فيما يتعلق بهذا الموضوع؟ هل يمكن نشر أكثر من شيء من نفس الإصدار؟

نظرًا لأن كل مكون إضافي لمدير الحزم يعتمد على بعض الملفات الإضافية لمدير الحزم (جميعها باستثناء git-tag )

أعتقد أن هذا افتراض خاطئ. هل يعتمد المكون الإضافي docker على أي ملف؟ قد لا يكون ذلك ضروريًا لذلك ربما يكون مثالًا سيئًا. إليك واحدًا آخر إذن: أنا مهتم باستخدام Auto مع sbt (أداة البناء الأكثر شيوعًا لـ Scala) ولا تحتوي على أي تهيئة JSON / XML يمكن قراءتها آليًا. يتم تكوين بنية sbt باستخدام كود Scala ولاستخراج أي معلومات حول البنية التي قد تحتاجها للتواصل مع sbt بطريقة ما.

هذا يحقق إدارة monorepo مستقلة بطريقة أبسط بكثير

يبدو أيضًا من هذا الموضوع أن الهدف هو استيعاب مشاريع monorepo مع مشاريع فرعية متعددة لها احتياجات نشر مختلفة. ماذا عن مشروع واحد ينتج أنواعًا مختلفة من القطع الأثرية؟ على سبيل المثال ، صورة Docker وأرشيف التكوين (يتم تحميلهما في مكان ما). أو إجراء GitHub الذي يمكن نشره كمكتبة لـ NPM وكإجراء على إصدارات GitHub.

يقوم كل مكون إضافي حاليًا بالالتزام والعلامات والدفع. هذا من شأنه أن يخلق الكثير من الضوضاء. من المحتمل أن تضطر إلى نقل إجراءات git هذه إلى الجوهر بحيث تحدث مرة واحدة فقط؟ على الرغم من أنك قد _ تريد_ التزامات منفصلة لكل package .

أعتقد أن هذه هي المشكلة الرئيسية في التنفيذ الحالي للمكونات الإضافية. هذا يعود إلى حيرتي حول الادعاء بأن كل أمر "يفعل شيئًا واحدًا بشكل جيد حقًا". في رأيي ، يجب أن يكون الخطاف publish الحقيقة _ فقط ينشر_ لمدير الحزم المحدد ، وليس إنشاء التزامات أو دفع علامات git. إذا كان بإمكان كل مكون إضافي للنشر التركيز فقط على تنفيذ تفاصيل مدير الحزم الخاص به ، فيمكن إعادة استخدام و / أو مشاركة الأجزاء الشائعة من العملية. هل لا يزال من الممكن تحقيق ذلك باستخدام Auto أم أنه متحيز للغاية للمشاريع الشبيهة بـ NPM؟