Definitelytyped: لماذا مونوريبو؟

1. يمكنك الانتقال مباشرة إلى المجلد الموجود أسفل types . على سبيل المثال ، لمشاهدة أنواع jquery ، انتقل إلى https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/jquery .
2. يمكنك البحث عن اسم المكتبة. على سبيل المثال ، إذا كنت تريد البحث عن المشكلات المفتوحة المتعلقة بـ lodash ، فيمكنك الانتقال إلى https://github.com/DefinitelyTyped/DefinitelyTyped/issues؟utf8=٪E2٪9C٪93&q=is٪ 3Aissue + هي٪ 3Aopen + Lodash ؛ أو يمكنك استخدام شريط البحث ، والذي سيعيد توجيهك إلى سلسلة الاستعلام المناسبة.

أليس هذا المونوريبو فوضى تامة؟

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

غير monorepo هو غير مبتدئ. في كثير من الأحيان ، سيحتاج المساهمون الذين يعدلون شيئًا ما في حزمة واحدة @types إلى تعديل العديد من الحزم النهائية لإصلاح الفواصل أو تمكين وظيفة جديدة ؛ هذه حريق قمامة مطلق مع سير عمل GitHub حيث لا توجد طريقة متكاملة لدمج تلك العلاقات العامة بطريقة ذرية مع استمرار تشغيل CI المعقول بناءً عليها جميعًا. إذا كنت تعتقد أنك تبحث في 4000 مجلد يمثل مشكلة ، فتخيل أننا نحاول الحفاظ على مزامنة إعدادات GitHub عبر 4000 إعادة توزيع.

في كثير من الأحيان ، سيحتاج المساهمون الذين يعدلون شيئًا ما في حزمة

لست على دراية بكتابة حزم @types/ ، لذلك ربما أفتقد شيئًا ...

ولكن أليس ما هو semver ؟
ما الذي يميز تطبيق حزمة @types/ مقابل أي حزمة أخرى في npm؟

أتوقع أن يعمل بنفس الطريقة: الرسم البياني التبعية حيث لديك على سبيل المثال. الحزمة @types/X وحزمة المصب @types/Y التي تستخدم @types/X . كلاهما يحتفظ به أشخاص مختلفون. عندما يتغير @types/X ، يتم نشره بإصدار مختلف ، لذلك لن يؤثر على الفور على @types/Y . قرر المساهم @types/Y لاحقًا التحديث إلى الإصدار الأحدث من @types/X وإصلاح المشكلات بسبب جميع التغييرات العاجلة.

ربما علاوة على ذلك ، لديك DefinitelyTyped meta-repository ، والذي يحتفظ فقط بقائمة من الارتباطات إلى type-repos. ثم بعض البرامج النصية publisher التي تظهر على تلك القائمة وتنشر جميع الحزم تحت @types/ npm-namespace.

أو إذا كان ذلك ممكنًا ، ما عليك سوى السماح للمنفذين بالنشر مباشرةً ضمن مساحة الاسم @types . لذلك نحن لسنا بحاجة إلى DefinitelyTyped meta-repo على الإطلاق.

https://github.com/npm/npm أيضًا مشكلات 2k.
https://github.com/moby/moby أكثر من ذلك.

أفضل حل هو أن المؤلف يحتفظ بالتعريف ، والذي تم تشجيعه دائمًا.

franklinyu عدد المشكلات ليس ما هو قيد السؤال. مع الأخذ في الاعتبار مجاميع الريبو> كتابة 4K ، فإن هذا العدد الهائل من المشكلات على ما يرام.

السؤال الحقيقي هو: ما المشكلة DefinitelyTyped تحاول حلها من خلال تجميع كل المطبوعات في ريبو واحد؟

لسوء الحظ ، لا يعمل semver بشكل جيد مع حزم الكتابة. يجب أن يتطابق إصدار major.minor من حزمة الأنواع مع major.minor لحزمة جافا سكريبت ، وإلا فلن يكون لدى الأشخاص أي فكرة عن إصدار @types لاستخدامه لأي إصدار حزمة جافا سكريبت معين.

على سبيل المثال ، الآن إذا قمت بتثبيت [email protected] ، فإنك تقوم أيضًا بتثبيت @types/[email protected] (الآن بسعر 4.14.109 ). ومع ذلك ، تخيل أن هناك خطأ في أنواع lodash (وثق بي يحدث هذا كثيرًا) ، وقام شخص ما بإصلاحه. الآن ماذا نطرح رقم الإصدار؟ حسب التعريف ، فإن أي تغيير في تعريفات النوع هو تغيير في كسر الواجهة (أو على الأقل إضافة واجهة). لكن لا يمكننا رفع الإصدار إلى 4.15.0 لأن هذه الأنواع مخصصة 4.14 ، وليس 4.15 . ونحن بالتأكيد لا نريد رفع رقم الإصدار إلى 5.0.0 . لذا بدلاً من ذلك ، قمنا بتحويل رقم الإصدار إلى 4.14.110 ، على الرغم من حدوث تغيير في الواجهة ، لأن الواجهة القديمة كانت غير دقيقة بالفعل.

@ aj-r حسنًا ، يجب أن يكون إصدار major.minor من @type/X مساويًا لإصدار major.minor من X ، وإذا كان هناك خطأ في @type/X أنت تستخدم إصدار patch لإصلاحه. هذا يبدو صحيحًا.

ما علاقة ذلك بالسؤال الأصلي: monorepo مقابل repos المنفصلة؟

عذرًا ، كان يجب أن أكون واضحًا - كنت أتحدث عن أحد تعليقاتك السابقة:

لكن أليس هذا ما هو _semver_؟

ما هي المشكلة التي تم كتابتها بالتأكيد لمحاولة حلها من خلال تجميع كل الأنواع في ريبو واحد؟

ما هي المشكلة هو تقسيم DT في 4000 اتفاقات إعادة الشراء جيثب منفصلة الذهاب الى حل؟

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

تقسيم هذا إلى الآلاف من subrepos يجعل كل ذلك أكثر صعوبة ، ولا يجعل أي شيء آخر أسهل. فلماذا نفعل ذلك؟

ما المشكلة التي سيحلها تقسيم DT إلى 4000 مستودعات GitHub منفصلة؟

1. كمستخدم تصل إلى المصادر بشكل أسرع. ليس عليك استخدام بعض التطبيقات الإضافية مثل TypeSearch للوصول إلى المصادر. في npm ، لديك رابط مباشر إلى الكتابة المطلوبة.

2. كمستخدم ، من الأسهل رؤية المشكلات الحالية وتقديم واحدة جديدة.

   • لا يتعين عليك البحث والتصفية على ريبو ضخم واحد مع> 2k مشكلة. ماذا لو نسي المراسل اتباع قواعد تسمية المشكلة (مثل [@types/name-of-package] Issue description )؟ أنت لا تجد أبدا القضايا المطلوبة.
   • على هذا النحو ، من غير الممكن تقديم التكرارات.

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

   • لا يتعين عليك (مرة أخرى) تصفية أي شيء للحصول على مشكلات تتعلق بكتابتك الملموسة. أقل من الممكن أن تفوت القضايا المطلوبة.
   • لديك دافع واضح للإبقاء على عدد المشكلات منخفضًا. رقم القضايا ليس مسؤولية مشتركة بعد الآن.
   • على هذا النحو ، من غير المحتمل أن تنسى المشكلات المعلقة هناك لسنوات .
     على سبيل المثال. هناك صفحة مشكلة واحدة من عام 2013 ، و 5 صفحات أعداد من عام 2014 ، وما إلى ذلك.

4. بصفتك عضوًا في فريق TypeScript ، قضيت وقتًا أطول في تحسين الكتابة نفسها (على سبيل المثال ، دعم jsdoc) ، بدلاً من صيانة / دمج / مراجعة الآلاف من الكتابة للعديد من حزم npm الموجودة هناك.
   في النظام البيئي الناضج ، هذا ما يجب أن يفعله المجتمع.

   • نحن ندير قواعد لينت على مستوى الريبو والتي تكتشف الأخطاء الشائعة

     حسنًا ، قم بتحرير الوبر مسبقًا مع جميع القواعد الموصى بها ، ونصح جميع المساهمين باستخدام أحدث إصدار من هذا الإعداد المسبق.

   • نعثر على تعريفات ونصلحها بأشياء تكسرها إصدارات المترجم المستقبلية.

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

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

ماذا يحدث عندما يقرر "المالك" المعلن ذاتيًا لأحد هذه المستودعات التوقف عن صيانته؟ هذا يحدث في كل وقت . كيف نتعقب أي الريبو هو "الأفضل" الحالي؟ ماذا يحدث إذا بدأوا في دمج التغييرات التي أدت إلى أشياء لا يمكننا نشرها على NPM؟

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

بصفتك عضوًا في فريق TypeScript ، قضيت وقتًا أطول في تحسين الكتابة نفسها (على سبيل المثال ، دعم jsdoc) ، بدلاً من صيانة / دمج / مراجعة الآلاف من الكتابة للعديد من حزم npm الموجودة هناك. في النظام البيئي الناضج ، هذا ما يجب أن يفعله المجتمع.

لقد جربنا هذا حرفياً ولم ينجح. كان DT مدفوعًا من قبل المجتمع فقط وأدى إلى تراكم طلبات السحب بعمق مئات. منذ ذلك الحين ، انخفض متوسط ​​الوقت اللازم لدمج العلاقات العامة من أسبوعين إلى 4 أيام (وهو الحد الأدنى المتعمد بحيث يكون لدى الأشخاص الوقت للتأثير في التغييرات) ، على الرغم من أن حجم العلاقات العامة قد انخفض من 200 تقريبًا / شهرًا إلى 1000 / شهر تقريبًا .

حسنًا ، أعتقد أن لدي إجابة على سؤالي الأصلي "لماذا monorepo؟":
لأنه من الأسهل على فريق TypeScript الحفاظ على تعريفات النوع (مع الأخذ في الاعتبار تبعيات النوع والتحديثات الذرية لحزم المصب ، CI ، الفحص ، إلخ.)

ما زلت أعتقد أن النموذج الذي يلعب فيه فريق TypeScript بهذا الدور الرئيسي في الحفاظ على آلاف الحزم في الغالب بمفرده غريب بعض الشيء. خاصة في عالم npm المعياري الذي يحركه المجتمع.

ولكن إذا كان هذا النموذج مناسبًا لك. ثم طيب: مبتسم:

@ art-in لا أعتقد أن القصد من ذلك هو إدارة جميع الأنواع من هذا الريبو ، إنه إدارة الأنواع التي لا توفرها الحزم نفسها. إذا أرادت الحزمة نشر أنواع لحزمتها ، فيمكنها القيام بذلك مباشرة في الحزمة. بالتأكيد ، النوع هو مجرد مكان يمكن فيه تجميع الأنواع دون الحاجة إلى موافقة المسؤول عن صيانة الحزمة الأصلية.