कोणीय / क्ली - पुस्तकालय के लिए नई कमांड का उपयोग करके कोणीय के लिए एक घटक पुस्तकालय के निर्माण का परीक्षण करना

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

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

देखते हैं कि यह क्या आया।

परीक्षणों के लिए, कोणीय / क्ली का नवीनतम स्थिर संस्करण लिया गया - 6.1.5 (09/04/2018)

बिल्कुल सही दुनिया

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

• परियोजनाओं की एकरूपता और त्वरित शुरुआत
• विकास की सुविधा
• वितरण में आसानी

तो, चलो शुरू से शुरू करते हैं।

अपनी खुद की लाइब्रेरी बनाने के लिए, हमें दो कदम उठाने की जरूरत है - एक नया प्रोजेक्ट बनाएं और उसमें एक लाइब्रेरी जोड़ें। सबसे पहले, एक नया प्रोजेक्ट बनाएं:

npx @angular/cli@latest new mylibapp 

कमांड निष्पादित करने के बाद, हम एक मानक देखेंगे (6 कोणीय के लिए, जो 5 वें संस्करण से भिन्न होता है) परियोजना जिसमें दो उप-परियोजनाएं बनाई जाएंगी - मुख्य mylibapp और mylibapp-e2e। कोणीय परियोजना को अब angular.json में वर्णित किया गया है।

अभी तक कोई पुस्तकालय नहीं हैं।

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

अब एक तीसरी उप-परियोजना बनाएं और एक पुस्तकालय बनाएं।

 cd mylibapp npx ng generate library mylib --prefix mlb 

किसी उपसर्ग को निर्दिष्ट करना आवश्यक नहीं है, लेकिन अन्य पुस्तकालयों के साथ अंतर नहीं करना बहुत ही वांछनीय है।

जैसा कि आप देख सकते हैं, अब, हमारी तीसरी लाइब्रेरी को तीसरी उप-परियोजना के रूप में जोड़ा गया है। इसका अपना एक अलग पैकेज है। json, tsconfig और karma.conf.js, जो आपको चोटिल अन्य परियोजनाओं के डर के बिना इसे कॉन्फ़िगर करने की अनुमति देता है। वैसे, यदि वांछित है, तो हम एक और पुस्तकालय जोड़ सकते हैं और यह एक अलग उपप्रोजेक्ट भी होगा। लेकिन यही कारण है कि पुस्तकालय को एक पूरी तरह से अलग परियोजना (उदाहरण के लिए। नेट में) द्वारा प्रतिष्ठित नहीं किया जा सकता है मुझे नहीं पता। और अगर e2e प्रोजेक्ट हाथ से निकालना मुश्किल नहीं है, तो मुख्य प्रोजेक्ट अब नहीं है। नतीजतन, रिपॉजिटरी में अतिरिक्त कोड दिखाई देता है, जो बहुत अच्छा नहीं है।

अब देखते हैं कि हमें कौन से उपकरण मिलते हैं। यह e2e के लिए tslint + कोडेलीजर, कर्म + चमेली और प्रोट्रैक्टर का एक गुच्छा है। यानी कोणीय परियोजना का मानक सेट, हमारे द्वारा लाई गई लाइब्रेरी के लिए विशिष्ट कुछ भी नहीं है। यह थोड़ा अजीब है, क्योंकि घटकों को देखने और उन्हें दस्तावेज़ीकरण में प्रस्तुत करने के लिए कुछ उपकरण (जैसे एक स्टोरीबुक ) बस एक होना चाहिए। लेकिन सब ठीक है, हम मान लेंगे कि यहाँ वे हमें पैंतरेबाज़ी के लिए कमरे में छोड़ दिया है।

चलो यह सुनिश्चित करने के लिए परीक्षण और लिंटर चलाएं कि सब कुछ काम करता है।

 npm test mylib npx ng lint mylib 

मेरे लिए सबकुछ ठीक हो गया, लेकिन क्रोम का उपयोग परीक्षण के लिए किया गया, जो भी अजीब है। मेरे पास उसके खिलाफ कुछ भी नहीं है, लेकिन बिल्ड सर्वर पर यह 90% नहीं होगा। वे एक ही Puppeteer का उपयोग क्यों नहीं किया स्पष्ट नहीं है।

संक्षेप में:

आकर्षण आते हैं

• एक नई परियोजना की त्वरित शुरुआत
• समान दृष्टिकोण

विपक्ष

• परियोजना में अतिरिक्त कोड
• स्पष्ट चीजों को अपने हाथों से समाप्त करने की आवश्यकता है।

अब तक, कुछ भी महत्वपूर्ण नहीं है, हम आगे खुदाई जारी रखते हैं।

डिज़ाइन

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

 npx ng build mylib 

 import { MylibModule } from "mylib"; ... @NgModule({ declarations: [ AppComponent, ], imports: [ BrowserModule, MylibModule ], providers: [], bootstrap: [AppComponent] }) 

 npm start 

सब कुछ हो जाने के बाद, हम अपने घटक को लाइब्रेरी से देखेंगे। लेकिन फिर से एक अति सूक्ष्म अंतर है - पुस्तकालय के लिए घड़ी मोड अभी तक नहीं किया गया है, क्या आपको हर बार पुस्तकालय को खुद बनाने की आवश्यकता है? वॉच केवल कोणीय / cli 6.2+ में दिखाई देगा। और बॉक्स से बाहर नहीं, इसके लिए आपको tsconfig.json में एक नया झंडा जोड़ना होगा

tsconfig.json

 "angularCompilerOptions": { "enableResourceInlining": true, } 

और फिर वॉच फ्लैग के साथ बिल्ड को चलाएं:

 ng build mylib --watch 

यदि किसी कारण से आप 6.2 के तहत cli का उपयोग करते हैं, तो आपको इसे स्वयं बनाना होगा, जो स्पष्ट रूप से, बुरा है।

अब एक नया कंपोनेंट जोड़ते हैं। ऐसा करने के लिए, मानक उत्पन्न घटक कमांड चलाएँ। इस तथ्य के कारण कि पुस्तकालय हमारी मुख्य परियोजना नहीं है, आपको प्रोजेक्ट ध्वज का उपयोग करना होगा, जो थोड़ा कष्टप्रद भी है (लेकिन यदि पुस्तकालय एक स्वतंत्र समाधान था ...)।

 npx ng generate component some-nice-image --project mylib 

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

लेकिन ट्री-शेकिंग बॉक्स से बाहर काम करना चाहिए। आइए लाइब्रेरी में एक और घटक बनाएं लेकिन हम इसे मुख्य परियोजना में उपयोग नहीं करेंगे। उत्पादन मोड में मुख्य परियोजना को एक साथ रखना

 npx build --prod 

और हम देखते हैं कि बंडल का आकार नहीं बदला है। ट्री-शेकिंग वास्तव में पुस्तकालयों के साथ काम करता है!

अब अच्छा होगा कि किसी तरह का नशा करने की कोशिश की जाए। चूंकि प्रत्येक प्रोजेक्ट का अपना पैकेज होता है। इसलिए हमें पहले लाइब्रेरी फोल्डर में जाना पड़ता है और npm इंस्टॉल कमांड को निष्पादित करना पड़ता है

 npm i -D @drag13/when-do npm i @drag13/round-to 

मैंने जानबूझकर उन्हें अलग-अलग तरीकों से यह जांचने के लिए रखा कि पैकर इसे बाद में कैसे संभालेंगे। सब कुछ समस्याओं के बिना सेट है। हम एक चेतावनी इकट्ठा करने और पाने की कोशिश करते हैं

'निर्भरता' के साथ npm संकुल वितरित करने की अनुशंसा नहीं की जाती है। कृपया ड्रैग 13 / राउंड-टू को 'सहकर्मी निर्भरता' से जोड़ने पर विचार करें, यह निर्भरता से दूर करता है

एनपीएम निर्भरता पैकेज वितरित करना वांछनीय नहीं है। कृपया सह -निर्भरता के लिए ड्रैग 13 / राउंड-निर्भरता को जोड़ने या यहां तक ​​कि निर्भरता से इसे हटाने पर विचार करें

और फिर त्रुटि:

निर्भरता ड्रैग 13 / राउंड-को स्पष्ट रूप से श्वेतसूची में होना चाहिए

ड्रैग 13 / राउंड-निर्भरता को स्पष्ट रूप से श्वेतसूची में जोड़ा जाना चाहिए।

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

बाकी एक नियमित कोणीय परियोजना के रूप में ही काम करता है।

संक्षेप में संक्षेप में कहें:

पेशेवरों:

• हम परिचित टीमों के साथ एक परिचित वातावरण में काम करते हैं
• बॉक्स से बाहर पेड़ हिल रहा है

विपक्ष:

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

और अंत में, प्रकाशन पर जाएं

प्रकाशन

सब कुछ यहीं है। कोणीय / cli प्रकाशित करने के लिए अच्छी तरह से स्थापित एनजी-पैगर का उपयोग करता है , जो स्वतंत्र रूप से हमारे कोड को npm प्रकाशन के लिए उपयुक्त पैकेज में संकलित करता है, जिससे पैकेज को छोड़ दिया जाता है। फ़ाइल की सेटिंग (जो छोटा नहीं है), न्यूनतमीकरण, विभिन्न स्वरूपों में पैकेजिंग (उदाहरण के लिए, UMD में) ।

अपने पैकेज को प्रकाशित करने के लिए (या देखें कि अंदर क्या है), आपको तीन कमांड चलाने की आवश्यकता है

 npx ng build --prod cd dist/mylib npm publish 

यदि आप प्रकाशित नहीं करना चाहते हैं, तो प्रकाशित आदेश को पैक से बदलें

नतीजतन, मुझे निम्नलिखित मिला:

पहले, चलिए package.json पर एक नज़र डालते हैं, जो हमारी लाइब्रेरी के मूल पैकेज.json से काफी अलग दिखता है।

जैसा कि आप देख सकते हैं, packagr ने हमारी निर्भरता को नहीं हटाया, हालांकि कुछ करते हैं। इसके अलावा, सैद्धांतिक रूप से पैकेज में वर्णित स्वरूपों की संख्या से प्रसन्न हैं। आगजनी (भले ही मैं उनमें से आधे को नहीं जानता हूं)।

पैकेज के अंदर UMD प्रारूप में एक छोटा और गैर-छोटा बंडल होता है, और आंतरिक कोणीय प्रारूप के कई और बंडल (fesm5, fesm2015)। लेकिन, सबसे महत्वपूर्ण बात, अब डेवलपर्स के सिर को इस बारे में चोट नहीं पहुंचेगी, जो कि अद्भुत है।

चलिए निष्कर्ष पर चलते हैं।

पेशेवरों:

• सुविधा
• तर्कसंगतता

कुल मिलाकर

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

दूसरी ओर, काम का एक बड़ा हिस्सा किया गया है, कार्यक्षमता लगातार विकसित हो रही है, और मुझे यकीन है कि समय के साथ, हम विकास के लिए एक उत्कृष्ट उपकरण प्राप्त करेंगे।