إنشاء مستودع أحادي مع مساحات عمل ليرنا وغزل

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

النظر في هيكل مشروعنا ، والتي ستكون ثلاث مكتبات تقع في الحزم / المجلد ، وكذلك package.json في الدليل الجذر.

├── package.json └── packages ├── app │  ├── index.js │  └── package.json ├── first │  ├── index.js │  └── package.json └── second ├── index.js └── package.json 

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

ستحتوي المكتبات الأولى والثانية على بساطة التجربة على وظيفة واحدة فقط في index.js ، ستُرجع كل منها سلسلة hello نيابة عن الوحدة النمطية. في المثال الأول ، سيبدو كما يلي:

 // packages/first/index.js const first = () => 'Hi from the first module'; module.exports = first; 

في وحدة التطبيق ، سوف نعرض رسالة Hi من التطبيق في وحدة التحكم ، وكذلك تحيات من مجموعتين أخريين:

 // packages/app/index.js const first = require('@monorepo/first'); const second = require('@monorepo/second'); const app = () => 'Hi from the app'; const main = () => { console.log(app()); console.log(first()); console.log(second()); }; main(); module.exports = { app, main }; 

بحيث يتوفر الأول والثاني في التطبيق ، ونشير إليهما على أنهما تبعيات في التبعيات .

بالإضافة إلى ذلك ، نضيف بادئة @ monorepo لكل اسم مكتبة في اسم القيمة أمام الاسم الرئيسي للحزمة إلى package.json المحلي.

 // packages/app/package.json { "name": "@monorepo/app", "version": "1.0.0", "main": "index.js", "license": "MIT", "dependencies": { "@monorepo/first": "^1.0.0", "@monorepo/second": "^1.0.0" } } 

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

مساحات عمل الغزل

سيكون اللمسة الأخيرة قبل إنشاء مستودع أحادي كامل التصميم من package.json في جذر مستودعنا. انتبه إلى خاصية مساحات العمل - لقد حددنا قيمة الحزم / * ، مما يعني "كافة المفاتيح الفرعية في مجلد الحزم ". في حالتنا ، هذا هو التطبيق ، الأول والثاني .

 // package.json { "name": "monorepo", "version": "1.0.0", "main": "packages/app/index.js", "license": "MIT", "private": true, "workspaces": [ "packages/*" ] } 

بالإضافة إلى ذلك ، "خاص": يجب تحديد true في package.json ، نظرًا لأن مساحات العمل متوفرة فقط في المشروعات الخاصة.

من أجل خلع كل شيء ، قم بتنفيذ أمر الغزل (مماثل لتثبيت الغزل أو تثبيت npm ) من الدليل الجذر. نظرًا لأن التبعيات الموجودة في وحدة التطبيق يتم تعريفها على أنها مساحات عمل في الحزمة الجذر. json ، في الواقع ، لن نقوم بتنزيل أي شيء من npm-registry ، ولكن ببساطة ربط ("link") الحزم الخاصة بنا.

 yarn 

الآن يمكننا تنفيذ الأمر العقدة. من الدليل الجذر الذي سيقوم بتشغيل البرنامج النصي من ملف الحزم / app / index.js .

 node . 

دعونا نرى كيف يعمل. عن طريق استدعاء الغزل ، أنشأنا روابط رمزية في node_modules لأدلةنا في مجلد الحزم .



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

الميزة المهمة التالية التي يمكنك الحصول عليها من العمل مع مساحات عمل الغزل هي تنظيم تخزين تبعيات الطرف الثالث.

أضف ليرنا

الخطوة الأولى في العمل مع lerna هي تثبيت الحزمة. عادةً ما يقومون بإجراء تثبيت عام ( yarn global add lerna أو npm i -g lerna ) ، ولكن إذا لم تكن متأكدًا مما إذا كنت تريد استخدام هذه المكتبة ، يمكنك استخدام المكالمة باستخدام npx .

سنقوم بتهيئة lerna من الدليل الجذر:

 lerna init 

في الواقع ، لقد قمنا بالعديد من الإجراءات في وقت واحد بمساعدة أمر واحد: أنشأنا مستودعًا git (إذا لم تتم تهيئته قبل ذلك) ، أنشأنا ملف lerna.json وقمنا بتحديث الحزمة root.json الخاصة بنا.

الآن في ملف lerna.json المنشأ حديثًا ، أضف سطرين - "npmClient": "yarn" و "useWorkspaces": true . يشير السطر الأخير إلى أننا نستخدم بالفعل مساحات عمل الغزل وليس هناك حاجة لإنشاء مجلد التطبيق / node_modules بروابط رمزية إلى الأول والثاني .

 // lerna.json { "npmClient": "yarn", "packages": [ "packages/*" ], "version": "1.0.0", "useWorkspaces": true } 

اختبارات مع ليرنا

لإظهار راحة العمل مع lerna أضف اختبارات لمكتباتنا .
من الدليل الجذر ، نقوم بتثبيت الحزمة للاختبار - jest . قم بتشغيل الأمر:

 yarn add -DW jest 

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

 // packages/first/test.js const first = require('.'); describe('first', () => { it('should return correct message', () => { const result = first(); expect(result).toBe('Hi from the first module'); }); }); 

نحتاج أيضًا إلى إضافة برنامج نصي لتشغيل الاختبارات في package.json لكل مكتبة من مكتباتنا:

 // packages/*/package.json ... "scripts": { "test": "../../node_modules/.bin/jest --colors" }, ... 

اللمسة النهائية سيتم تحديث الحزمة الجذر. json . أضف برنامجًا نصيًا للاختبار سوف يستدعي اختبار تشغيل lerna - تيار . تحدد المعلمة التالية لتشغيل lerna الأمر الذي سيتم استدعاؤه في كل حزمة من الحزم الخاصة بنا من الحزم / المجلد ، وستسمح لنا العلامة --stream بمشاهدة نتائج النتائج في الجهاز الطرفي.

نتيجة لذلك ، تبدو package.json من الدليل الجذر كما يلي:

 // package.json { "name": "monorepo", "version": "1.0.0", "main": "packages/app/index.js", "license": "MIT", "private": true, "workspaces": [ "packages/*" ], "scripts": { "test": "lerna run test --stream" }, "devDependencies": { "jest": "^24.7.1", "lerna": "^3.13.2" } } 

الآن ، لإجراء الاختبارات ، نحتاج فقط إلى تشغيل الأمر من جذر مشروعنا:

 yarn test 

ترقية الإصدار مع Lerna

ستكون المهمة الشائعة التالية ، والتي يمكن ليرنا التعامل معها بالجودة ، تحديث إصدارات الحزمة. تخيل أنه بعد تنفيذ الاختبارات ، قررنا ترقية مكتباتنا من 1.0.0 إلى 2.0.0. للقيام بذلك ، ما عليك سوى إضافة السطر "update: version": "نسخة lerna - no-push" إلى حقل البرامج النصية في الحزمة الجذر. json ، ثم قم بتشغيل تحديث الغزل: الإصدار من الدليل الجذر. تتم إضافة علامة - no-push بحيث لا يتم إرسال التغييرات بعد تحديث الإصدار إلى المستودع البعيد ، وهو ما تقوم به lerna افتراضيًا (بدون هذه العلامة).

نتيجة لذلك ، ستبدو الحزمة الجذر الخاصة بنا.

 // package.json { "name": "monorepo", "version": "1.0.0", "main": "packages/app/index.js", "license": "MIT", "private": true, "workspaces": [ "packages/*" ], "scripts": { "test": "lerna run test --stream", "update:version": "lerna version --no-push" }, "devDependencies": { "jest": "^24.7.1", "lerna": "^3.13.2" } } 

قم بتشغيل البرنامج النصي لتحديث الإصدار:

 yarn update:version 

بعد ذلك ، سيُطلب منا تحديد الإصدار الذي نريد التبديل إليه:



بالنقر فوق Enter ، نحصل على قائمة الحزم التي يتم فيها تحديث الإصدار.



نؤكد التحديث بإدخال y ونصلك رسالة حول التحديث الناجح.



إذا حاولنا تشغيل أمر git status ، فلنحصل على شيء نرسله إلى الرسالة ، ونعمل الشجرة النظيفة ، لأن لا يقوم lerna version بتحديث إصدارات الحزمة فحسب ، بل يقوم أيضًا بإنشاء التزام وعلامة بالإشارة إلى الإصدار الجديد (الإصدار 2.0 في حالتنا).

استنتاج

تُظهر هذه الأمثلة مائة من جميع الاحتمالات التي لدى ليرنا مع مساحات عمل الغزل . لسوء الحظ ، لم أجد حتى الآن تعليمات مفصلة للعمل مع المستودعات الإحيائية باللغة الروسية ، لذلك يمكننا افتراض أن البداية قد تحققت!

رابط إلى مستودع مشروع الاختبار.