اسمي عزت رازيتدينوف ، لقد كنت في ياندكس منذ 12 عامًا ، وأدير خدمة تطوير الواجهة في Y. Real Estate. اليوم أود أن أتحدث عن monorepository. إذا كان لديك مستودع واحد فقط في العمل - تهانينا ، فأنت تعيش بالفعل في مستودع واحد. الآن لماذا يحتاج الآخرون إليها.
وفقًا لمارينا بيرسكوكوفا ، رئيس خدمة تطوير Yandex.Mart API ، زرع جدي مونوريبا ، ونمت مونوريبا كبيرة وكبيرة.
- جربنا في Yandex طرقًا مختلفة للعمل مع العديد من الخدمات ولاحظنا - بمجرد توفر أكثر من خدمة ، تبدأ الأجزاء الشائعة حتماً في الظهور: الطرز ، الأدوات المساعدة ، الأدوات ، أجزاء الكود ، القوالب ، المكونات. والسؤال هو: أين نضع كل هذا؟ بالطبع ، يمكنك نسخ ولصق ، يمكننا أن نفعل ذلك ، لكنني أريد ذلك بشكل جميل.
حاولنا حتى كيان مثل SVN externals لأولئك الذين يتذكرون. حاولنا git وحدات فرعية. لقد حاولنا حزم npm عندما ظهرت. لكن كل هذا كان طويلاً أو شيء ما. كنت تدعم أي حزمة ، والعثور على خطأ ، وجعل التصحيحات. ثم تحتاج إلى إصدار نسخة جديدة ، والذهاب إلى الخدمات ، والترقية إلى هذا الإصدار ، والتحقق من أن كل شيء يعمل ، وإجراء الاختبارات ، والعثور على الخطأ ، والعودة إلى مستودع المكتبة ، وإصلاح الخطأ ، وإصدار الإصدار الجديد ، والانتقال إلى الخدمات ، والتحديث ، وما إلى ذلك. دائرة. لقد تحولت إلى ألم.
ثم فكرنا فيما إذا كان ينبغي لنا أن نجتمع في مستودع واحد. خذ جميع خدماتنا ومكتباتنا ، وقم بنقلها وتطويرها في مستودع واحد. كان هناك الكثير من المزايا. أنا لا أقول أن هذا النهج مثالي ، ولكن من وجهة نظر الشركة وحتى قسم عدة مجموعات ، تظهر مزايا كبيرة.
بالنسبة لي شخصياً ، فإن الشيء الأكثر أهمية هو atomicity of commits ، حيث أنني كمطور ، يمكنني إصلاح المكتبة وتجاوز جميع الخدمات وإجراء التغييرات وإجراء الاختبارات والتحقق من أن كل شيء يعمل ودفعه إلى الرئيسي وكل هذا مع تغيير واحد. لا حاجة لإعادة بناء ونشر وتحديث أي شيء.
ولكن إذا كان كل شيء جيدًا ، فلماذا لم ينتقل الجميع إلى المستودع الأحادي حتى الآن؟ بالطبع ، هناك أيضا عيوب في ذلك.
وفقًا لمارينا بيرسكوكوفا ، رئيس خدمة تطوير واجهة برمجة تطبيقات Yandex.Map ، زرع جدي مونوريبا ، ونمت مونوريبا كبيرة وكبيرة. هذه حقيقة وليست مزحة. إذا قمت بتجميع العديد من الخدمات في مستودع واحد ، فمن المحتم أن تنمو. وإذا كنا نتحدث عن git ، التي تسحب جميع الملفات بالإضافة إلى محفوظاتها بأكملها لوجود كامل لرمزك ، فهذه مساحة كبيرة على القرص.
المشكلة الثانية هي الحقن في السيد. لقد قمت بإعداد طلب تجمع ، واستعرضت مراجعة ، فأنت مستعد لدمجه. واتضح أن شخصًا ما تمكن من التقدم إليك وتحتاج إلى حل النزاعات. لقد قمت بحل النزاعات ، مرة أخرى على استعداد لتدفق ، ومرة أخرى لم يكن لديك الوقت. يتم حل هذه المشكلة ، وهناك أنظمة قائمة انتظار دمج ، عندما يقوم روبوت خاص بأتمتة هذا العمل ، وحارات تجمع الطلبات ، ويحاول حل التعارضات ، إذا كان ذلك ممكنًا. إذا لم يستطع ذلك ، فإنه يتصل بالمؤلف. ومع ذلك ، مثل هذه المشكلة موجودة. هناك حلول ترفع مستوى ذلك ، لكن عليك أن تضع ذلك في الاعتبار.
هذه هي النقاط الفنية ، ولكن هناك أيضًا نقاط تنظيمية. افترض أن لديك عدة فرق تقدم عدة خدمات مختلفة. عندما ينتقلون إلى مستودع واحد ، تبدأ مسؤوليتهم في التآكل. لأنهم أطلقوا سراحهم ، خرجوا في الإنتاج - حدث شيء ما. نبدأ في استخلاص المعلومات. اتضح أنه مطور من فريق آخر ألزم شيئًا بالشفرة العامة ، فقد سحبناه ، ولم نصدره ، ولم نراه ، كل شيء محطم. وليس واضحا من المسؤول. من المهم فهم واستخدام جميع الطرق الممكنة: اختبارات الوحدة ، اختبارات التكامل ، linter - كل ما هو ممكن للحد من هذه المشكلة من تأثير رمز واحد على جميع الخدمات الأخرى.
ومن المثير للاهتمام ، من هو إلى جانب ياندكس واللاعبون الآخرون يستخدمون المستودع الأحادي؟ الكثير من الناس. هذه هي رد فعل ، Jest ، بابل ، Ember ، نيزك ، الزاوي. يفهم الناس - أنه من الأسهل والأرخص والأسرع تطوير ونشر حزم npm من مستودع واحد أكثر من عدة مستودعات صغيرة. الشيء الأكثر إثارة للاهتمام هو أنه جنبا إلى جنب مع هذه العملية ، بدأت تطوير أدوات العمل مع مستودع تخزين. فقط عنهم وأريد التحدث.
كل شيء يبدأ بإنشاء monorepository. تُعرف أداة الواجهة الأمامية الأكثر شهرة في العالم بهذا الاسم lerna.
فقط افتح المستودع الخاص بك ، قم بتشغيل npx lerna init ، وسوف يطرح عليك بعض الأسئلة الموحية ويضيف عدد قليل من الكيانات إلى نسخة العمل الخاصة بك. الكيان الأول هو تكوين lerna.json ، الذي يشير إلى حقلين على الأقل: الإصدار من البداية إلى النهاية لجميع الحزم الخاصة بك وموقع الحزم الخاصة بك في نظام الملفات. بشكل افتراضي ، تتم إضافة جميع الحزم إلى مجلد الحزم ، ولكن يمكنك تكوين هذا كما تريد ، حتى يمكنك إضافتها إلى الجذر ، ويمكن ليرنا التقاطها أيضًا.
الخطوة التالية هي كيفية إضافة مستودعاتك إلى المستودع الأحادي ، وكيفية نقلها؟
ما الذي نريد تحقيقه؟ على الأرجح ، لديك بالفعل نوعًا من المستودع ، في هذه الحالة A و B.
هذه خدمتان ، كل منهما في مستودعها الخاص ، ونريد نقلها إلى مستودع أحادي جديد في مجلد الحزم ، ويفضل أن يكون ذلك مع سجل من الالتزامات ، بحيث يمكنك إلقاء اللوم على git ، وتسجيل git ، وما إلى ذلك.
هناك أداة استيراد ليرنا لهذا الغرض. يمكنك ببساطة تحديد موقع مستودعك ، وتقوم ليرنا بنقله إلى مونوريبو الخاص بك. في الوقت نفسه ، تأخذ أولاً قائمة بجميع التعديالت وتعديل كل التزام وتغيير المسار إلى الملفات من الجذر إلى الحزم / package_name وتطبقها واحدة تلو الأخرى وتفرضها في مستودعك الأحادي. في الواقع ، كل التزام يعد ، وتغيير مسارات الملفات في ذلك. أساسا ، ليرنا يفعل السحر لك. إذا قرأت الكود المصدري ، فهناك أوامر git يتم تنفيذها ببساطة في تسلسل معين.
هذه هي الطريقة الأولى. له عيب: إذا كنت تعمل في شركة توجد فيها عمليات إنتاج ، حيث يكتب الأشخاص بالفعل نوعًا ما من التعليمات البرمجية ، وسوف تقوم بترجمتها إلى monorep ، فمن غير المحتمل أن تقوم بذلك في يوم واحد. سوف تحتاج إلى معرفة وتكوين والتحقق من أن كل شيء يبدأ والاختبارات. لكن الناس ليس لديهم عمل ، فهم يواصلون القيام بشيء ما.
لتحقيق انتقال أكثر سلاسة إلى mono-rap ، توجد أداة مثل git subtree. هذا شيء أكثر تطوراً ، ولكن في الوقت نفسه من git ، لا يسمح لك فقط باستيراد مستودعات فردية إلى مستودع أحادي بواسطة نوع ما من البادئة ، ولكن أيضًا تبادل التغييرات جيئة وذهابا. وهذا يعني أنه يمكن بسهولة تطوير الفريق الذي يصنع الخدمة في مستودعه الخاص ، بينما يمكنك سحب تغييراتها من خلال الشجرة الفرعية git وإجراء التغييرات الخاصة بك ودفعها مرة أخرى من خلال git subtree push. ويعيش مثل هذا في الفترة الانتقالية لطالما أردت.
وعندما تقوم بإعداد كل شيء ، وتحقق من أن جميع الاختبارات قيد التشغيل ، وأن النشر يعمل ، وتم تهيئة CI / CD بالكامل ، يمكنك القول إن الوقت قد حان للمضي قدماً. للفترة الانتقالية ، حل كبير ، أوصي.
حسنًا ، لقد نقلنا مستودعاتنا إلى مستودع واحد ، ولكن أين السحر في مكان ما؟ لكننا نريد تسليط الضوء على الأجزاء المشتركة واستخدامها بطريقة ما. ولهذا هناك آلية "ملزمة التبعية". ما هو التبعية ملزمة؟ هناك أداة lerna bootstrap ، الأمر الذي يشبه تثبيت npm ، يعمل فقط على تثبيت npm في جميع الحزم الخاصة بك.
لكن هذا ليس كل شيء. بالإضافة إلى ذلك ، فهي تبحث عن التبعيات الداخلية. يمكنك استخدام حزمة أخرى في حزمة واحدة داخل مستودعك. على سبيل المثال ، إذا كان لديك الحزمة A ، والتي تعتمد على Jest في هذه الحالة ، فهناك الحزمة B ، والتي تعتمد على Jest والحزمة A. إذا كانت الحزمة A أداة شائعة ، ومكونًا شائعًا ، فإن الحزمة B هي خدمة بها الاستخدامات.
يعرّف Lerna هذه التبعيات الداخلية ويستبدل فعليًا هذه التبعية برابط رمزي على نظام الملفات.
بعد تشغيل lerna bootstrap ، داخل مجلد node_modules مباشرة ، بدلاً من المجلد الفعلي A ، يظهر رابط رمزي يؤدي إلى المجلد مع الحزمة A. هذا ملائم للغاية لأنه يمكنك تحرير الشفرة داخل الحزمة A والتحقق من النتيجة في الحزمة B مباشرةً تشغيل الاختبارات والتكامل والوحدات ، كل ما تريد. عملية التطوير مبسطة إلى حد كبير ، لم تعد بحاجة إلى إعادة تجميع الحزمة أ ، نشر ، توصيل الحزمة ب. تم إصلاحها هنا فقط ، تم فحصها هناك.
يرجى ملاحظة أنه إذا نظرت إلى مجلدات node_modules ، وهناك تباطؤ ، قمنا بتكرار الوحدة النمطية المثبتة. بشكل عام ، يعد وقتًا طويلاً عند بدء تشغيل lerna bootstrap ، انتظر حتى يتوقف كل شيء ، نظرًا لوجود الكثير من العمل المتكرر ، يتم الحصول على تبعيات مكررة في كل حزمة.
لتسريع عملية تثبيت التبعيات ، يتم استخدام آلية رفع التبعيات. الفكرة بسيطة للغاية: يمكنك نقل التبعيات العامة إلى node_modules الجذر.
إذا حددت الخيار - hist (هذه ترقية من اللغة الإنجليزية) ، فستنتقل كل التبعيات تقريبًا إلى وحدات الجذر node_modules. ويعمل دائما تقريبا. نودا مرتبة بحيث إذا لم تجد التبعيات في مستواها ، فإنها تبدأ في البحث في مستوى أعلى ، إن لم يكن هناك ، مستوى آخر أعلى وهلم جرا. لا شيء تقريبا يتغير. ولكن في الواقع ، أخذنا ونسختنا تبعياتنا ، ونقلنا التبعيات إلى الجذر.
في الوقت نفسه ، ليرنا ذكي بما فيه الكفاية. إذا كان هناك أي تعارض ، على سبيل المثال ، إذا كانت الحزمة A تستخدم Jest الإصدار 1 ، واستخدمت الحزمة B الإصدار 2 ، فستظهر واحدة منها ، وستظل الثانية في مستواها. هذا هو ما تفعله npm فعليًا داخل مجلد node_modules العادي ، كما يحاول أيضًا إلغاء اكتشاف التبعيات والقيام إلى أقصى درجة بحملها إلى الجذر.
لسوء الحظ ، هذا السحر لا يعمل دائمًا ، خاصة مع الأدوات ، مع بابل ، مع Jest. يحدث غالبًا أنه يبدأ ، نظرًا لأن Jest لديه نظامه الخاص لحل الوحدات النمطية ، يبدأ Noda في التأخير ، ويلقي خطأً. خاصة في مثل هذه الحالات التي لا تتعامل فيها الأداة مع التبعيات التي انتقلت إلى الجذر ، يوجد خيار nohoist ، والذي يسمح لك بالإشارة إلى أن هذه الحزم لا تنقل إلى الجذر ، اتركها في مكانها.
إذا قمت بتحديد --nohoist = jest ، فستذهب كل التبعيات باستثناء jest إلى الجذر ، وستظل jest عند مستوى الحزمة. لا عجب أن أعطيت مثالاً على ذلك - إنه مزاح يعاني من مشاكل مع هذا السلوك ، ولا يساعد أي شخص في هذا الأمر.
إضافة أخرى لاسترداد التبعية:
إذا كان لديك قبل ذلك حزمة منفصلة lock.json لكل خدمة ، لكل حزمة ، ثم أثناء رفع كل شيء يتحرك لأعلى ، ويظل هناك حزمة واحدة lock.json واحدة فقط. هذا مناسب من وجهة نظر التدفق إلى الرئيسي ، وحل النزاعات. بمجرد قتل الجميع ، وهذا كل شيء.
لكن كيف يحقق ليرنا هذا؟ هي عدوانية جدا مع npm. عندما تحدد رافعة ، فإنه يأخذ package.json في الجذر ، ويدعمه ، ويستبدل آخر به ، ويجمع كل تبعياتك فيه ، ويدير تثبيت npm ، ويوضع كل شيء تقريبًا في الجذر. ثم يزيل هذا package.json المؤقت ، ويعيد لك. إذا قمت بعد ذلك بتشغيل أي أمر باستخدام npm ، على سبيل المثال ، إزالة npm ، فلن يفهم npm ما حدث ولماذا ظهرت فجأة كل التبعيات في الجذر. تنتهك Lerna مستوى التجريد ، فهي تزحف إلى الأداة ، التي تقل عن مستواها.
كان الرجال من Yarn أول من لاحظوا هذه المشكلة وقالوا: ما الذي نعذبه ، فلنفعل كل شيء من أجلك أصليًا ، حتى يعمل كل شيء خارج الصندوق.
يستطيع الغزل فعل الشيء نفسه خارج الصندوق: ربط التبعيات ، إذا رأى أن الحزمة B تعتمد على الحزمة A ، فسيقوم بإنشاء رابط لك ، مجانًا. إنه يعرف كيفية رفع التبعيات ، هل يقوم بذلك افتراضيًا ، كل شيء يضيف إلى الجذر. مثل lerna ، يمكن أن يترك yarn.lock الوحيد في جذر المستودع. الجميع الغزل. قفل لم تعد بحاجة.
تم تكوينه بطريقة مماثلة. لسوء الحظ ، يفترض الغزل أن تتم إضافة جميع الإعدادات إلى package.json ، أعرف أن هناك أشخاصًا يحاولون سحب جميع إعدادات الأدوات من هناك ، ولم يتبق سوى حد أدنى. لسوء الحظ ، لم يتعلم الغزل بعد تحديد ذلك في ملف آخر ، package.json فقط. هناك خياران جديدان ، أحدهما جديد والآخر إلزامي. نظرًا لأنه من المفترض أن مستودع الجذر لن ينشر أبدًا ، فإن الغزل يتطلب القطاع الخاص = true ليتم تحديده هناك.
ولكن يتم تخزين إعدادات مساحات العمل في نفس المفتاح. يشبه الإعداد إلى حد كبير إعدادات lerna ، وهناك حقل حزم حيث تحدد موقع الحزم الخاصة بك ، وهناك خيار nohoist ، مشابه جدًا لخيار nohoist في lerna. ما عليك سوى تحديد هذه الإعدادات والحصول على نفس البنية كما في lerna. ذهبت كل التبعيات الشائعة إلى الجذر ، وتظل تلك المحددة في مفتاح nohoist في مستواها.
أفضل جزء هو أنه يمكن ليرنا العمل مع الغزل والتقاط إعداداته. يكفي تحديد حقلين في lerna.json ، ستفهم lerna على الفور أنك تستخدم الغزل ، وتذهب إلى package.json ، احصل على جميع الإعدادات من هناك وتعمل معها. تعرف هاتان الأداتان بالفعل بعضهما البعض وتعملان معًا.
ولماذا لم يتم تقديم الدعم في npm حتى الآن إذا كانت العديد من الشركات الكبيرة تستخدم مستودعًا أحاديًا؟
يقولون أن كل شيء سيكون ، ولكن في الإصدار السابع. الدعم الأساسي في السابع ، مدد - في الثامن. تم نشر هذا المنشور منذ شهر ، ولكن في نفس الوقت ، لا يزال التاريخ غير معروف متى سيتم إصدار npm السابعة. نحن في انتظاره للحاق في النهاية مع الغزل.
عندما يكون لديك العديد من الخدمات في مستودع واحد ، فإن السؤال الذي يطرح نفسه حتما هو كيفية إدارتها حتى لا تذهب إلى كل مجلد ، وليس تشغيل الأوامر؟ هناك عمليات ضخمة لهذا الغرض.
يحتوي الغزل على أمر مساحة عمل الغزل ، متبوعًا باسم الحزمة واسم الأمر. نظرًا لأن الغزل من المربع ، على عكس npm ، يمكنه القيام بكل الأشياء الثلاثة: تشغيل الأوامر الخاصة به ، وإضافة تبعية على jest ، وتشغيل البرامج النصية من package.json ، مثل test ، ويمكن أيضًا تشغيل الملفات القابلة للتنفيذ من مجلد node_modules / .bin. سوف يعلمك بمساعدة الاستدلال سوف يفهم ما تريد. أنها مريحة للغاية لاستخدام مساحة عمل الغزل لعمليات نقطة على حزمة واحدة.
يوجد أمر مشابه يسمح لك بتنفيذ أمر على جميع الحزم التي لديك.
حدد فقط أوامرك بكل الحجج.
من الايجابيات ، من المناسب للغاية إدارة فرق مختلفة. من السلبيات ، على سبيل المثال ، من المستحيل تشغيل أوامر shell. افترض أنني أريد حذف كافة مجلدات الوحدات النمطية للعقدة ، لا يمكنني تشغيل مساحات عمل الغزل بتشغيل rm.
لا يمكن تحديد قائمة الحزم ، على سبيل المثال ، أريد إزالة التبعية في عبوتين فقط ، واحدة فقط في كل مرة أو بشكل منفصل.
حسنًا ، إنه يتعطل في الخطأ الأول. إذا كنت ترغب في إزالة التبعية من جميع الطرود - وفي الحقيقة ، هناك اثنتان منها فقط ، لكنني لا أريد التفكير في مكانها ، لكني أريد فقط إزالتها - ثم لن يسمح الغزل بذلك ، فسيتعطل في الحالة الأولى حيث هذه الحزمة ليست في التبعيات. هذا ليس ملائمًا جدًا ، في بعض الأحيان تريد تجاهل الأخطاء ، قم بتشغيل جميع الحزم.
لدى Lerna مجموعة أدوات أكثر إثارة للاهتمام ، هناك أمران منفصلان للتنفيذ و exec. يمكن تنفيذ Run من البرامج النصية من package.json ، وعلى عكس الغزل ، فإنه يمكن تصفية كل شيء حسب الحزمة ، يمكنك تحديد - نطاق ، يمكنك استخدام العلامات النجمية ، globs ، كل شيء عالمي تمامًا. يمكنك تشغيل هذه العمليات بشكل متوازٍ ، ويمكنك تجاهل الأخطاء من خلال مفتاح التبديل - no-الكفالة.
إكسيك مشابه جدا. على عكس الغزل ، فإنه يتيح لك ليس فقط تشغيل الملفات القابلة للتنفيذ من node_modules.bin ، ولكن أيضًا تنفيذ أي أوامر shell عشوائية. على سبيل المثال ، يمكنك إزالة node_modules أو تشغيل بعضها ، ما تريد. ويدعم نفس الخيار.
أدوات مريحة للغاية ، بعض الإيجابيات. هذا هو الحال عندما غزل lerna الدموع ، هو في المستوى الصحيح من التجريد. هذا هو بالضبط ما يحتاجه ليرنا: تبسيط العمل مع العديد من الحزم في monorepe.
مع monoreps هناك واحد أكثر ناقص. عندما يكون لديك CI / CD ، لا يمكنك تحسينه. لمزيد من الخدمات لديك ، كلما استغرق الأمر كل هذا. لنفترض أنك بدأت اختبار جميع الخدمات لكل طلب تجمع ، وكلما زاد ذلك ، كلما طال العمل. يمكن استخدام عمليات انتقائية لتحسين هذه العملية. سأذكر ثلاث طرق مختلفة. يمكن استخدام الأولين منها ليس فقط في monorep ، ولكن أيضًا في مشاريعك ، إذا لم تستخدم هذه الأساليب لسبب ما.
الأول هو مراحل الوبر ، والتي تسمح لك بتشغيل linter ، الاختبارات ، كل ما تريد ، فقط للملفات التي تغيرت أو سيتم الالتزام بها في هذا الالتزام. قم بتشغيل الوبر بأكمله ليس على المشروع بأكمله ، ولكن فقط على الملفات التي تغيرت.
الإعداد بسيط جدا. ضعي الوبر المتقن والأقوي والخطافات المسبقة ونقول أنه عند تغيير أي ملف js ، فأنت بحاجة إلى تشغيل eslint. وبالتالي ، يتم تسريع عملية التحقق المسبق إلى حد كبير. خاصة إذا كان لديك العديد من الخدمات ، مستودع أحادي كبير جدًا. بعد ذلك ، يعد تشغيل eslint على جميع الملفات باهظ التكلفة ، ويمكنك تحسين خطافات precommit على الوبر بهذه الطريقة.
إذا كتبت اختبارات على Jest ، فسيحتوي أيضًا على أدوات لتشغيل الاختبارات بشكل انتقائي.
يتيح لك هذا الخيار منحها قائمة بالملفات المصدر والعثور على جميع الاختبارات التي تؤثر بطريقة أو بأخرى على هذه الملفات. ما الذي يمكن استخدامه بالاقتران مع الوبر؟ يرجى ملاحظة ، أنا هنا لا حدد جميع ملفات js ، ولكن فقط المصدر. نحن نستبعد ملفات js بأنفسهم مع اختبارات في الداخل ، ونحن ننظر فقط في المصدر. نبدأ findRelatedTests ونعمل على تسريع تشغيل الوحدة إلى حد كبير قبل الإعداد المسبق ، كما يحلو لك.
ويرتبط الأسلوب الثالث مع monospositories. هذا هو lerna ، الذي يمكنه تحديد الحزم التي تغيرت مقارنةً بالالتزام الأساسي. هذا على الأرجح ليس عن الخطافات ، ولكن حول CI / CD: Travis أو أي خدمة أخرى تستخدمها.
يتوفر الأمر "تشغيل" و "exec" منذ ذلك الحين ، والذي يسمح لك بتشغيل أي أمر فقط في الحزم التي تغيرت منذ نوع من الالتزام. في الحالات البسيطة ، يمكنك تحديد معالج إذا قمت بصب كل شيء فيه. إذا كنت تريد بمزيد من الدقة ، فمن الأفضل تحديد الالتزام الأساسي لطلب التجمع الخاص بك من خلال أداة CI / CD ، فسيكون هذا اختبارًا أكثر صدقًا.
نظرًا لأن lerna يعرف كل التبعيات الموجودة داخل الحزم ، يمكنه اكتشاف التبعيات غير المباشرة أيضًا. إذا قمت بتغيير المكتبة A ، والتي يتم استخدامها في المكتبة B ، والتي يتم استخدامها في الخدمة C ، فسوف تفهم lerna ذلك. , . , C — , . lerna .
, :
c lerna ,
yarn workspaces
.
, . , . . ? , , , . , , . , - . , Babel. , , . . , .
أود أن أقول شكراً لزملائي: ميشا ميشانغا تروشيف وجوشا بيسدين. لقد أمضوا وقتًا طويلاً في دراسة الأدوات التي استعرضناها اليوم وتبادلنا خبرتهم ومعرفتهم. هذا كل شيء ، شكرا.