एक monorepository में विकास। यैंडेक्स रिपोर्ट

मेरा नाम अज़त रजीतदीनोव है, मैं 12 साल से यैंडेक्स में हूं, मैं वाई-रियल एस्टेट में इंटरफ़ेस विकास सेवा का प्रबंधन करता हूं। आज मैं एक मोनोरेपोजिटरी के बारे में बात करना चाहूंगा। यदि आपके पास काम पर केवल एक भंडार है - बधाई हो, तो आप पहले से ही एक एकल भंडार में रहते हैं। अब दूसरों को इसकी आवश्यकता क्यों है।

Yandex.Map API डेवलपमेंट सर्विस की प्रमुख मरीना पेरस्कोकोवा के अनुसार, मेरे दादा ने एक मोनोरपा लगाया था, और एक मोनोरपा बड़ा, बड़ा हो गया है।

- हम यैंडेक्स में कई सेवाओं के साथ काम करने के विभिन्न तरीकों की कोशिश की और ध्यान दिया - जैसे ही आपके पास एक से अधिक सेवाएं हैं, अनिवार्य रूप से सामान्य हिस्से दिखाई देने लगते हैं: मॉडल, उपयोगिताओं, उपकरण, कोड के टुकड़े, टेम्पलेट, घटक। सवाल यह है: यह सब कहां रखा जाए? बेशक, आप कॉपी-पेस्ट कर सकते हैं, हम कर सकते हैं, लेकिन मैं इसे खूबसूरती से चाहता हूं।

हमने याद रखने वालों के लिए SVN एक्सटर्नल जैसी इकाई की भी कोशिश की। हमने गिट सबमॉडल्स की कोशिश की। हमने npm संकुल की कोशिश की जब वे दिखाई दिए। लेकिन यह सब कुछ लंबा था, या कुछ और। आप किसी भी पैकेज का समर्थन करते हैं, एक त्रुटि पाते हैं, सुधार करते हैं। फिर आपको एक नया संस्करण जारी करने की आवश्यकता है, सेवाओं के माध्यम से जाएं, इस संस्करण में अपग्रेड करें, जांचें कि सब कुछ काम करता है, परीक्षण चलाएं, त्रुटि ढूंढें, पुस्तकालय के साथ भंडार पर वापस जाएं, त्रुटि को ठीक करें, नया संस्करण जारी करें, सेवाओं के माध्यम से जाएं, अपडेट करें और इसी तरह। वृत्त। यह सिर्फ दर्द में बदल गया।



फिर हमने इस बारे में सोचा कि क्या हमें एक रिपॉजिटरी में एक साथ आना चाहिए। हमारी सभी सेवाओं और पुस्तकालयों को लें, एक भंडार में स्थानांतरण और विकास करें। इसके बहुत सारे फायदे थे। मैं यह नहीं कह रहा हूं कि यह दृष्टिकोण आदर्श है, लेकिन कंपनी और यहां तक ​​कि कई समूहों के विभाग के दृष्टिकोण से, महत्वपूर्ण लाभ दिखाई देते हैं।

मेरे लिए व्यक्तिगत रूप से, सबसे महत्वपूर्ण बात यह है कि आवागमन की परमाणुता, कि एक डेवलपर के रूप में, मैं पुस्तकालय को ठीक कर सकता हूं, सभी सेवाओं को बायपास कर सकता हूं, परिवर्तन कर सकता हूं, परीक्षण चला सकता हूं, सत्यापित कर सकता हूं कि सब कुछ काम करता है, इसे मास्टर में धकेलें, और यह सब एक बदलाव के साथ। कुछ भी पुनर्निर्माण, प्रकाशित, अद्यतन करने की आवश्यकता नहीं है।

लेकिन अगर सब कुछ इतना अच्छा है, तो हर कोई अभी तक मोनो-रिपॉजिटरी में क्यों नहीं गया है? बेशक, इसमें नुकसान भी हैं।



Yandex.Map API डेवलपमेंट सर्विस की प्रमुख मरीना पेरस्कोकोवा के अनुसार, मेरे दादा ने एक मोनोरपा लगाया था, और एक मोनोरपा बड़ा, बड़ा हो गया है। यह एक सच्चाई है, मजाक नहीं। यदि आप एक एकल भंडार में कई सेवाएं एकत्र करते हैं, तो यह अनिवार्य रूप से बढ़ता है। और अगर हम git के बारे में बात कर रहे हैं, जो आपके कोड के संपूर्ण अस्तित्व के लिए सभी फाइलों और उनके पूरे इतिहास को बाहर निकालता है, तो यह एक बड़ी डिस्क स्थान है।

दूसरी समस्या मास्टर में इंजेक्शन है। आपने एक पूल अनुरोध तैयार किया, समीक्षा के माध्यम से गया, आप इसे मर्ज करने के लिए तैयार हैं। और यह पता चला है कि कोई व्यक्ति आपसे आगे निकलने में कामयाब रहा और आपको संघर्षों को हल करने की आवश्यकता है। आपने संघर्षों को हल किया, फिर से डालने के लिए तैयार हैं, और फिर आपके पास समय नहीं है। यह समस्या हल हो रही है, मर्ज कतार सिस्टम हैं, जब एक विशेष रोबोट इस काम को स्वचालित करता है, पूल अनुरोधों को स्वीकार करता है, यदि यह हो सकता है, तो संघर्षों को हल करने की कोशिश करता है। यदि वह नहीं कर सकता है, तो वह लेखक को बुलाता है। हालाँकि, ऐसी समस्या मौजूद है। ऐसे समाधान हैं जो इसे स्तर देते हैं, लेकिन आपको इसे ध्यान में रखने की आवश्यकता है।

ये तकनीकी बिंदु हैं, लेकिन संगठनात्मक भी हैं। मान लीजिए कि आपके पास कई टीमें हैं जो कई अलग-अलग सेवाएं प्रदान करती हैं। जब वे एक एकल भंडार में जाते हैं, तो उनकी जिम्मेदारी मिटने लगती है। क्योंकि उन्होंने एक रिलीज की, उत्पादन में लुढ़का - कुछ टूट गया। हम डिब्रीफिंग शुरू करते हैं। यह पता चला है कि यह किसी अन्य टीम का एक डेवलपर है जिसने सामान्य कोड के लिए कुछ किया है, हमने इसे खींच लिया, इसे असंबंधित, इसे नहीं देखा, सब कुछ टूट गया। और यह स्पष्ट नहीं है कि कौन जिम्मेदार है। सभी संभावित तरीकों को समझना और उनका उपयोग करना महत्वपूर्ण है: यूनिट परीक्षण, एकीकरण परीक्षण, लिंटर - सब कुछ जो अन्य सभी सेवाओं पर एक कोड के प्रभाव की इस समस्या को कम करना संभव है।

दिलचस्प है, यांडेक्स और अन्य खिलाड़ियों के अलावा और कौन-कौन मोनो-रिपॉजिटरी का उपयोग करता है? बहुत सारे लोग। ये हैं रिएक्ट, जेस्ट, बैबेल, एम्बर, उल्का, कोणीय। लोग समझते हैं - कई छोटे रिपॉजिटरी से एकल रिपॉजिटरी से एनपीएम पैकेज विकसित करना और प्रकाशित करना अधिक आसान, सस्ता, तेज है। सबसे दिलचस्प बात यह है कि इस प्रक्रिया के साथ, एक मोनोरेपोजिटरी के साथ काम करने के उपकरण विकसित होने लगे। उनके बारे में और मैं बात करना चाहता हूं।

यह सब एक monorepository बनाने के साथ शुरू होता है। इसके लिए दुनिया का सबसे प्रसिद्ध फ्रंट-एंड टूल लर्न कहा जाता है।



बस अपनी रिपॉजिटरी खोलें, npx lerna init चलाएं, यह आपसे कुछ विचारोत्तेजक सवाल पूछेगा और आपकी वर्किंग कॉपी में कुछ इकाइयाँ जोड़ेगा। पहली इकाई lerna.json config है, जो कम से कम दो क्षेत्रों को इंगित करता है: फ़ाइल सिस्टम में आपके सभी पैकेजों का एंड-टू-एंड संस्करण और आपके पैकेजों का स्थान। डिफ़ॉल्ट रूप से, सभी पैकेज संकुल फ़ोल्डर में जोड़ दिए जाते हैं, लेकिन आप जैसे चाहें इसे कॉन्फ़िगर कर सकते हैं, आप उन्हें रूट में भी जोड़ सकते हैं, लर्न इसे भी उठा सकते हैं।

अगला कदम यह है कि मोनो रिपॉजिटरी में अपनी रिपॉजिटरी को कैसे जोड़ा जाए, उन्हें कैसे ट्रांसफर किया जाए?

हम क्या हासिल करना चाहते हैं? सबसे अधिक संभावना है, आपके पास पहले से ही कुछ प्रकार का भंडार है, इस मामले में ए और बी।



ये दो सेवाएं हैं, प्रत्येक अपने स्वयं के भंडार में, और हम उन्हें संकुल फ़ोल्डर में नए मोनो-रिपॉजिटरी में स्थानांतरित करना चाहते हैं, अधिमानतः कमिट के इतिहास के साथ, ताकि आप गिट दोष, गिट लॉग, और इसी तरह बना सकें।



इसके लिए एक लर्ना आयात उपकरण है। आप बस अपनी रिपॉजिटरी का स्थान निर्दिष्ट करते हैं, और लार्ना इसे आपके मोनोरेपो में स्थानांतरित करता है। उसी समय, वह, सबसे पहले, सभी कमिट्स की एक सूची लेती है, प्रत्येक कमिट को संशोधित करती है, रूट से फाइल को पैकेज / पैकेज_नाम में बदलती है, और उन्हें एक के बाद एक लागू करती है, उन्हें आपके मोनो-रिपॉजिटरी में ओवरले करती है। वास्तव में, प्रत्येक प्रतिबद्ध तैयार करता है, इसमें फ़ाइल पथ बदल रहा है। अनिवार्य रूप से, lerna आपके लिए जादू का काम करता है। यदि आप स्रोत कोड पढ़ते हैं, तो एक निश्चित क्रम में बस git कमांड निष्पादित होते हैं।

यह पहला तरीका है। इसकी एक खामी है: यदि आप किसी ऐसी कंपनी में काम करते हैं, जहां उत्पादन प्रक्रियाएं होती हैं, जहां लोग पहले से ही किसी तरह का कोड लिख रहे हैं, और आप उन्हें एक मोनोरप में तब्दील करने जा रहे हैं, तो यह संभावना नहीं है कि आप इसे एक दिन में करेंगे। आपको यह पता लगाने, कॉन्फ़िगर करने, सत्यापित करने की आवश्यकता होगी कि सब कुछ शुरू होता है, परीक्षण। लेकिन लोगों के पास काम नहीं है, वे कुछ न कुछ करते रहते हैं।



मोनो-रैप के लिए एक चिकनी संक्रमण के लिए, गिट उपट्री जैसे एक उपकरण है। यह एक और अधिक परिष्कृत चीज है, लेकिन एक ही समय में देशी के लिए, जो आपको न केवल व्यक्तिगत रिपॉजिटरी को कुछ प्रकार के उपसर्गों द्वारा मोनो-रिपॉजिटरी में आयात करने की अनुमति देता है, बल्कि आगे और पीछे परिवर्तन भी करता है। यही है, जो टीम सेवा बनाती है उसे आसानी से अपने स्वयं के भंडार में और विकसित किया जा सकता है, जबकि आप उनके बदलावों को गिट सबट्री पुल के माध्यम से खींच सकते हैं, अपने स्वयं के परिवर्तन कर सकते हैं और उन्हें गिट उपट्री पुश के माध्यम से वापस धक्का दे सकते हैं। और जब तक आप चाहें तब तक संक्रमण अवधि में इस तरह से रहें।

और जब आप सब कुछ सेट कर लेते हैं, तो जांच लें कि सभी परीक्षण चल रहे हैं, परिनियोजन कार्य कर रहा है, संपूर्ण CI / CD कॉन्फ़िगर किया गया है, आप कह सकते हैं कि यह आगे बढ़ने का समय है। संक्रमण की अवधि के लिए, एक महान समाधान, मैं सुझाता हूं।

ठीक है, हमने अपनी रिपॉजिटरी को एक मोनो-रिपॉजिटरी में स्थानांतरित कर दिया, लेकिन जादू कहीं नहीं है? लेकिन हम आम हिस्सों को उजागर करना चाहते हैं और किसी तरह उनका उपयोग करना चाहते हैं। और इसके लिए एक "निर्भरता बंधन" तंत्र है। निर्भरता बंधन क्या है? एक lerna बूटस्ट्रैप टूल है, एक कमांड जो npm इंस्टॉल के समान है, बस आपके सभी पैकेजों में npm इंस्टॉल चलाता है।



लेकिन यह सब नहीं है। इसके अलावा, वह आंतरिक निर्भरता की तलाश में है। आप अपने भंडार के अंदर एक पैकेज में दूसरे का उपयोग कर सकते हैं। उदाहरण के लिए, यदि आपके पास पैकेज ए है, जो इस मामले में जेस्ट पर निर्भर करता है, तो पैकेज बी है, जो जेस्ट और पैकेज ए पर निर्भर करता है। यदि पैकेज ए एक सामान्य उपकरण है, तो एक सामान्य घटक है, तो पैकेज बी एक ऐसी सेवा है जिसमें यह है का उपयोग करता है।

लेर्ना इस तरह की आंतरिक निर्भरता को परिभाषित करता है और शारीरिक रूप से इस निर्भरता को फाइल सिस्टम पर एक प्रतीकात्मक लिंक के साथ बदल देता है।





आपके द्वारा lerna बूटस्ट्रैप चलाने के बाद, right_modules फ़ोल्डर के अंदर, भौतिक फ़ोल्डर A के बजाय, एक प्रतीकात्मक लिंक दिखाई देता है जो पैकेज A. के साथ फ़ोल्डर की ओर जाता है। यह बहुत सुविधाजनक है क्योंकि आप पैकेज A के अंदर कोड को संपादित कर सकते हैं और तुरंत पैकेज B में परिणाम की जांच कर सकते हैं। , परीक्षण, एकीकरण, इकाइयों, जो भी आप चाहते हैं, चलाएं। विकास बहुत सरल है, आपको पैकेज ए को फिर से इकट्ठा करने, प्रकाशित करने, पैकेज बी को जोड़ने की आवश्यकता नहीं है। यह सिर्फ यहां तय किया गया है, वहां जांचा गया है।

कृपया ध्यान दें कि यदि आप नोड_मॉडल फोल्डर को देखते हैं, और वहाँ जस्ट है, तो हमने स्थापित मॉड्यूल को डुप्लिकेट किया है। सामान्य तौर पर, यह काफी लंबा समय होता है जब आप लर्न बूटस्ट्रैप शुरू करते हैं, तब तक प्रतीक्षा करें जब तक कि सब कुछ बंद न हो जाए, इस तथ्य के कारण कि किसी भी तरह के दोहराए जाने वाले काम में है, प्रत्येक पैकेज में डुप्लिकेट निर्भरताएं प्राप्त होती हैं।

निर्भरता की स्थापना को गति देने के लिए, निर्भरता बढ़ाने के लिए तंत्र का उपयोग किया जाता है। यह विचार बहुत सरल है: आप सामान्य निर्भरता को मूल नोड_मॉड्यूल में ले जा सकते हैं।



यदि आप --होस्ट विकल्प को निर्दिष्ट करते हैं (यह अंग्रेजी से अपग्रेड है), तो लगभग सभी निर्भरताएं मूल नोड_मॉड्यूल्स में चली जाएंगी। और यह लगभग हमेशा काम करता है। नोडा इतनी व्यवस्थित है कि अगर उसे अपने स्तर पर निर्भरताएं नहीं मिली हैं, तो वह एक स्तर अधिक खोजना शुरू कर देता है, यदि कोई अन्य स्तर नहीं है, तो उच्चतर। लगभग कुछ भी नहीं बदलता है। लेकिन वास्तव में, हमने अपनी निर्भरता को कम कर दिया और निर्भरता को जड़ तक स्थानांतरित कर दिया।

वहीं, लर्ना काफी स्मार्ट है। यदि कोई संघर्ष है, उदाहरण के लिए, यदि पैकेज ए ने जेस्ट संस्करण 1 का उपयोग किया है, और पैकेज बी ने संस्करण 2 का उपयोग किया है, तो उनमें से एक पॉप अप होगा, और दूसरा अपने स्तर पर रहेगा। यह लगभग वही है जो npm वास्तव में सामान्य नोड_मॉडल फ़ोल्डर के अंदर कर रहा है, यह निर्भरता को कम करने की कोशिश करता है और अधिकतम उन्हें जड़ तक ले जाता है।

दुर्भाग्य से, यह जादू हमेशा काम नहीं करता है, विशेष रूप से औजारों के साथ, बैबेल के साथ, जेस्ट के साथ। अक्सर ऐसा होता है कि वह शुरू करता है, क्योंकि जेस्ट के पास मॉड्यूल को हल करने के लिए अपनी प्रणाली है, नोडा पिछड़ना शुरू करता है, एक त्रुटि फेंकता है। विशेष रूप से ऐसे मामलों के लिए जब उपकरण रूट पर गए निर्भरता के साथ सामना नहीं करता है, नोहिस्ट विकल्प है, जो आपको यह इंगित करने की अनुमति देता है कि ये पैकेज रूट पर स्थानांतरित नहीं होते हैं, उन्हें जगह में छोड़ दें।



यदि आप --nohoist = jest निर्दिष्ट करते हैं, तो jest को छोड़कर सभी निर्भरताएँ रूट पर चली जाएंगी, और jest पैकेट स्तर पर बना रहेगा। कोई आश्चर्य नहीं कि मैंने ऐसा एक उदाहरण दिया - यह ऐसा मजाक है जिसमें इस व्यवहार के साथ समस्याएं हैं, और कोई भी व्यक्ति इसके साथ मदद नहीं करता है।

निर्भरता वसूली का एक और प्लस:



यदि इससे पहले कि आपके पास प्रत्येक पैकेज के लिए प्रत्येक पैकेज के लिए अलग-अलग पैकेज-लॉक था। तब, जब आप hoyed होते हैं, तो सब कुछ बढ़ जाता है, और केवल पैकेज-लॉक। json ही रहता है। यह मास्टर में डालना, संघर्षों को हल करने के दृष्टिकोण से सुविधाजनक है। एक बार सभी को मार दिया गया था, और यह बात है।

लेकिन लर्न इसे कैसे प्राप्त करता है? वह npm के साथ काफी आक्रामक है। जब आप लहरा को निर्दिष्ट करते हैं, तो यह आपके पैकेज को ले जाता है। जड़ में ले जाता है, इसका बैक अप लेता है, इसके लिए एक और विकल्प देता है, इसमें आपकी सभी निर्भरता को एकत्रित करता है, एनपीएम इंस्टॉल चलाता है, लगभग सब कुछ रूट में डाल दिया जाता है। फिर यह अस्थायी पैकेज। Json हटा देता है, आपका पुनर्स्थापित करता है। यदि उसके बाद आप npm के साथ कोई कमांड चलाते हैं, उदाहरण के लिए, npm निकालें, npm समझ में नहीं आएगा कि क्या हुआ, क्यों सभी निर्भरताएं अचानक रूट पर दिखाई दीं। Lerna अमूर्तता के स्तर का उल्लंघन करती है, वह उपकरण में क्रॉल करती है, जो उसके स्तर से नीचे है।

यार्न के लोग इस समस्या पर ध्यान देने वाले पहले व्यक्ति थे और उन्होंने कहा: हम क्या पीड़ा दे रहे हैं, आइए हम आपके लिए सब कुछ मूल रूप से करते हैं, ताकि सब कुछ बॉक्स से बाहर हो जाए।



यार्न पहले से ही बॉक्स से बाहर एक ही काम कर सकता है: निर्भरताएं टाई, अगर वह देखता है कि पैकेज बी पैकेज ए पर निर्भर करता है, तो वह आपके लिए एक सिमलिंक बना देगा, मुफ्त में। वह जानता है कि निर्भरता कैसे बढ़ाई जाए, क्या यह डिफ़ॉल्ट रूप से होता है, सब कुछ जड़ तक जुड़ जाता है। लर्न की तरह, यह केवल यार्न को छोड़ सकता है। भंडार की जड़ में। हर कोई यार्न करता है। अब आपको कोई ज़रूरत नहीं है।



यह एक समान तरीके से कॉन्फ़िगर किया गया है। दुर्भाग्य से, यार्न मानता है कि सभी सेटिंग्स को package.json में जोड़ा जाता है, मुझे पता है कि ऐसे लोग हैं जो केवल एक न्यूनतम छोड़कर, वहाँ से सभी उपकरणों की सभी सेटिंग्स को हटाने की कोशिश करते हैं। दुर्भाग्य से, यार्न ने अभी तक इसे किसी अन्य फ़ाइल में निर्दिष्ट करने के लिए नहीं सीखा है, केवल package.json। दो नए विकल्प हैं, एक नया और एक अनिवार्य। चूंकि यह मान लिया गया है कि रूट रिपॉजिटरी कभी प्रकाशित नहीं होगी, इसलिए यार्न को निजी = सही होना चाहिए।

लेकिन कार्यक्षेत्रों के लिए सेटिंग्स एक ही कुंजी में संग्रहीत की जाती हैं। सेटिंग लर्न सेटिंग्स के समान है, एक पैकेज फ़ील्ड है जहां आप अपने पैकेजों का स्थान निर्दिष्ट करते हैं, और एक नोहिस्ट विकल्प होता है, जो लर्न में नोहिस्ट विकल्प के समान है। बस इन सेटिंग्स को निर्दिष्ट करें और लर्न में समान संरचना प्राप्त करें। सभी सामान्य निर्भरताएं मूल में गईं, और नोहिस्ट कुंजी में निर्दिष्ट लोग अपने स्तर पर बने रहे।



सबसे अच्छी बात यह है कि लर्न यार्न के साथ काम कर सकता है और इसकी सेटिंग्स उठा सकता है। यह lerna.json में दो क्षेत्रों को निर्दिष्ट करने के लिए पर्याप्त है, lerna तुरंत समझ जाएगा कि आप यार्न का उपयोग कर रहे हैं, package.json में जाएं, वहां से सभी सेटिंग्स प्राप्त करें और उनके साथ काम करें। ये दो उपकरण पहले से ही एक दूसरे के बारे में जानते हैं और एक साथ काम करते हैं।



और क्यों npm पर समर्थन अभी तक नहीं किया गया है अगर इतनी बड़ी कंपनियां एक मोनो-रिपॉजिटरी का उपयोग करती हैं?

^{_{स्लाइड से लिंक करें}}

वे कहते हैं कि सब कुछ होगा, लेकिन सातवें संस्करण में। सातवें में मूल समर्थन, विस्तारित - आठवें में। यह पोस्ट एक महीने पहले जारी किया गया था, लेकिन एक ही समय में, तारीख अभी भी अज्ञात है जब सातवां एनपीएम जारी किया जाएगा। हम अंत में यार्न के साथ उसे पकड़ने के लिए इंतजार कर रहे हैं।

जब आपके पास एक मोनो-रिपॉजिटरी में कई सेवाएं हैं, तो सवाल अनिवार्य रूप से उठता है कि उन्हें कैसे प्रबंधित किया जाए ताकि प्रत्येक फ़ोल्डर में न जाएं, कमांड न चलाएं? इसके लिए बड़े पैमाने पर ऑपरेशन किए जा रहे हैं।





यार्न में एक यार्न वर्कस्पेस कमांड है, उसके बाद पैकेज का नाम और कमांड का नाम है। चूंकि बॉक्स से यार्न, एनपीएम के विपरीत, तीनों चीजें कर सकता है: अपनी खुद की कमांड चलाएं, जेस्ट पर निर्भरता जोड़ें, पैकेज से स्क्रिप्ट चलाएँ। टेस्ट की तरह, और यह भी नोड_मॉड्यूस / .bin फ़ोल्डर से निष्पादन योग्य फाइलें चला सकता है। वह आपके लिए सिखाएगा हेरास्टिक की मदद से वह समझ जाएगा कि आप क्या चाहते हैं। एक पैकेज पर बिंदु संचालन के लिए यार्न कार्यक्षेत्र का उपयोग करना बहुत सुविधाजनक है।

एक समान कमांड है जो आपको सभी पैकेजों पर एक कमांड निष्पादित करने की अनुमति देता है जो आपके पास है।



सभी तर्कों के साथ सिर्फ अपनी आज्ञाओं को इंगित करें।



पेशेवरों से, विभिन्न टीमों को चलाने के लिए यह बहुत सुविधाजनक है। उदाहरण के लिए, शेल कमांड चलाना असंभव है। मान लीजिए कि मैं सभी नोड मॉड्यूल फ़ोल्डर को हटाना चाहता हूं, मैं यार्न वर्कस्पेस को आरएम नहीं चला सकता।
संकुल की सूची निर्दिष्ट करना असंभव है, उदाहरण के लिए, मैं केवल दो पैकेजों में निर्भरता को दूर करना चाहता हूं, केवल बदले में या व्यक्तिगत रूप से।

खैर, वह पहली ही गलती पर दुर्घटनाग्रस्त हो गया। अगर मैं सभी पैकेजों से निर्भरता को दूर करना चाहता हूं - और वास्तव में, उनमें से केवल दो के पास है, लेकिन मैं यह नहीं सोचना चाहता कि यह कहां है, लेकिन मैं इसे निकालना चाहता हूं - फिर यार्न इसे अनुमति नहीं देगा, यह पहली स्थिति में दुर्घटनाग्रस्त हो जाएगा जहां यह पैकेज निर्भरता में नहीं है। यह बहुत सुविधाजनक नहीं है, कभी-कभी आप त्रुटियों को अनदेखा करना चाहते हैं, सभी पैकेजों के माध्यम से चलाते हैं।



लारना के पास बहुत अधिक दिलचस्प टूलकिट है, दो अलग-अलग रन और निष्पादन कमांड हैं। रन पैकेज.जसन से स्क्रिप्ट निष्पादित कर सकता है, और यार्न के विपरीत, यह पैकेज द्वारा सब कुछ फ़िल्टर कर सकता है, आप निर्दिष्ट कर सकते हैं - स्पेस, आप तारांकन, ग्लब्स का उपयोग कर सकते हैं, सब कुछ काफी सार्वभौमिक है। आप इन ऑपरेशनों को समानांतर में चला सकते हैं, आप -नो-जमानत स्विच के माध्यम से त्रुटियों को अनदेखा कर सकते हैं।



Exec बहुत समान है। यार्न के विपरीत, यह आपको न केवल नोड_मॉड्यूल्स.बीन से निष्पादन योग्य फ़ाइलों को चलाने की अनुमति देता है, बल्कि किसी भी मनमाने ढंग से शेल कमांड को भी निष्पादित करता है। उदाहरण के लिए, आप नोड_मॉड्यूल हटा सकते हैं या कुछ भी बना सकते हैं, जो आप चाहते हैं। और एक ही विकल्प समर्थित है।



बहुत सुविधाजनक उपकरण, कुछ प्लसस। यह वह स्थिति है जब लर्न यार्न को फाड़ देता है, यह अमूर्तता के सही स्तर पर है। यह वही है जो लर्न की आवश्यकता है: मोनोरेप में कई पैकेजों के साथ काम को सरल बनाएं।

मोनोरेप्स के साथ एक और माइनस होता है। जब आपके पास CI / CD होगी, तो आप इसे ऑप्टिमाइज़ नहीं कर सकते। आपके पास जितनी अधिक सेवाएं हैं, उतनी ही अधिक समय लगेगा। मान लीजिए कि आप प्रत्येक पूल अनुरोध के लिए सभी सेवाओं का परीक्षण शुरू करते हैं, और जितना अधिक हो, काम उतना ही लंबा होता है। इस प्रक्रिया को अनुकूलित करने के लिए चयनात्मक संचालन का उपयोग किया जा सकता है। मैं तीन अलग-अलग तरीकों का नाम दूंगा। उनमें से पहले दो का उपयोग न केवल मोनोरेप में किया जा सकता है, बल्कि आपकी परियोजनाओं में भी किया जा सकता है, यदि किसी कारण से आप इन विधियों का उपयोग नहीं करते हैं।

पहला है लिंट-स्टेज, जो आपको लिंटर, टेस्ट, सब कुछ जो आप चाहते हैं, केवल उन फाइलों को चलाने की अनुमति देता है जो इस कमिट में बदल गए हैं या शुरू हो जाएंगे। पूरे लिंट को अपने पूरे प्रोजेक्ट पर न चलाएं, बल्कि केवल उन फाइलों पर चलाएं जो बदल गई हैं।





सेटअप बहुत सरल है। लिंट-स्टेज्ड, हस्की, प्री-कमिट-हुक लगाएं और कहें कि किसी भी जेएस-फाइल को बदलते समय आपको एस्किट चलाने की जरूरत है। इस प्रकार, पूर्व-प्रतिबद्ध जांच में बहुत तेजी आती है। खासकर यदि आपके पास कई सेवाएं हैं, तो एक बहुत बड़ी मोनो-रिपॉजिटरी। फिर सभी फाइलों पर एस्लेंट चलाना बहुत महंगा है, और आप इस तरह से लिंट पर प्रीकोमाइट-हुक का अनुकूलन कर सकते हैं।



यदि आप जेस्ट पर परीक्षण लिखते हैं, तो इसमें चुनिंदा रूप से चलने वाले परीक्षण के उपकरण भी हैं।



यह विकल्प आपको इसे स्रोत फ़ाइलों की एक सूची देने और उन सभी परीक्षणों को खोजने की अनुमति देता है जो इन फ़ाइलों को प्रभावित करते हैं। लिंट-मंचन के साथ संयोजन में क्या इस्तेमाल किया जा सकता है? कृपया ध्यान दें, यहां मैं सभी js फ़ाइलों को निर्दिष्ट नहीं कर रहा हूं, लेकिन केवल स्रोत। हम अंदर परीक्षणों के साथ खुद को जेएस फाइलों को बाहर करते हैं, हम केवल स्रोत को देखते हैं। हम खोज शुरू करते हैं। आप अपनी इच्छानुसार प्री-कॉम्पट या प्रीशप करने के लिए यूनिट को तेज कर सकते हैं।

और तीसरी विधि monorepositories के साथ जुड़ी हुई है। यह लर्न है, जो यह निर्धारित कर सकता है कि आधार प्रतिबद्ध की तुलना में कौन से पैकेज बदले गए हैं। यह हुक के बारे में नहीं बल्कि आपके CI / CD: ट्रैविस या आपके द्वारा उपयोग की जाने वाली किसी अन्य सेवा के बारे में अधिक संभावना है।





रन और एक्ज़ीक्यूट कमांड के पास तब से विकल्प है, जो आपको किसी भी कमांड को केवल उन पैकेजों में चलाने की अनुमति देता है, जो किसी प्रकार के प्रतिबद्ध होने के बाद बदल गए हैं। साधारण मामलों में, आप एक विज़ार्ड निर्दिष्ट कर सकते हैं यदि आप उसमें सब कुछ डालते हैं। यदि आप अधिक सटीक रूप से चाहते हैं, तो अपने सीआई / सीडी टूल के माध्यम से अपने पूल अनुरोध का आधार प्रतिबद्ध निर्दिष्ट करना बेहतर है, तो यह अधिक ईमानदार परीक्षण होगा।

चूंकि lerna संकुल के अंदर सभी निर्भरता जानता है, इसलिए यह अप्रत्यक्ष निर्भरता का भी पता लगा सकता है। यदि आप लाइब्रेरी A को बदलते हैं, जिसका उपयोग लाइब्रेरी B में किया जाता है, जिसका उपयोग सेवा C में किया जाता है, तो Lerna इसे समझेगा। , . , C — , . lerna .

, : c lerna , yarn workspaces .

, . , . . ? , , , . , , . , - . , Babel. , , . . , .

मैं अपने सहकर्मियों को धन्यवाद कहना चाहता हूं: मिशा मिशंगा ट्रोशेव और गोशा बेसेडिन। उन्होंने उन उपकरणों का अध्ययन करने में काफी समय बिताया जो हमने आज समीक्षा की और अपने अनुभव और ज्ञान को साझा किया। वह सब, धन्यवाद।