मैं कोणीय 4+ के लिए बिल्कुल नया हूँ। अब हमारे पास उत्पादन में कोणीय 4+ ऐप है। यह काफी अच्छी तरह से चला गया जहां एक और ऐप अब वांछित है।

नए ऐप में कुछ मूल ऐप की आवश्यकता होगी, मुख्य रूप से सेवा क्षेत्र में (जैसे लॉगिंग, ऑथ, कॉन्फिगरेशन)।

मुझे यकीन नहीं है कि इन सेवाओं को और अधिक क्रॉस-प्रोजेक्ट साझा करने योग्य इकाई में तोड़ने के बारे में कैसे जाना है। क्या साझा सेवाओं को NPM मॉड्यूल में बनाने के लिए कोई अच्छी मार्गदर्शिका है? क्या वह ओवरकिल है और क्या मुझे कुछ ऐसा ही करना चाहिए, जैसे git सबमॉड्यूल? मुझे इस विषय पर एक अच्छा संसाधन नहीं मिला है।

2
BRass 31 अक्टूबर 2017, 00:23

2 जवाब

सबसे बढ़िया उत्तर

मुझे यकीन है कि जहां मैं इस पर उतरा वह सबसे उचित नहीं है। उस ने कहा, मैं अपने मामले में परियोजनाओं में कुछ जेएस कोड साझा करने के लिए इंजीनियर से अधिक नहीं चाहता था।

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

यह मेरे लिए जो समाप्त होता है वह एक /lib निर्देशिका है जो सामान्य /src निर्देशिका के बाहर है। हालाँकि, मेरी tsconfig.json फ़ाइल में मैंने /lib JS को अंदर खींच लिया है और इसे /src के साथ संकलित कर रहा हूँ:

"include": [
    "src/**/*.ts",
    "lib/**/*.ts"
  ],

यह सामान्य जेएस फाइलों को बाहर निकालने के लिए एक बहुत ही सरल तरीके से समाप्त होता है, उन्हें साझा करने के उद्देश्यों के लिए एक अलग रेपो में रखता है, और उन्हें प्रत्येक उपभोग करने वाली परियोजना में संकलित करता है जैसे कि वे परियोजना में ही थे। NPM पैकेज, निर्भरता आदि के साथ खिलवाड़ करने की कोई आवश्यकता नहीं है। कुछ git कमांड यदि यह आपकी रुचि रखते हैं:

साझा रेपो के लिए रिमोट सेट करें:

git remote add -f SHARED_JS_REMOTE <Your Shared Repo URL Here>

साझा रेपो को उपभोग करने वाली परियोजना में जोड़ें:

git subtree add --prefix=lib/shared-js SHARED_JS_REMOTE master

रेपो का उपभोग करने से वापस साझा रेपो में परिवर्तन पुश करें:

git fetch SHARED_JS_REMOTE master
git subtree push --prefix=lib/shared-js SHARED_JS_REMOTE master

साझा रेपो से वापस उपभोग करने वाले रेपो में परिवर्तन खींचें:

git fetch SHARED_JS_REMOTE master
git subtree pull --prefix=lib/shared-js SHARED_JS_REMOTE master
1
BRass 7 नवम्बर 2017, 00:24

यह एक अच्छा सवाल है जो आपकी परियोजनाओं को संरचित करने के तरीके के बारे में अधिक है। और आपने अपने उत्तर में दो संभावित समाधानों का उल्लेख पहले ही कर दिया है।

समाधान #1: NPM लाइब्रेरी

आपके सिस्टम के पुन: प्रयोज्य घटकों को पुस्तकालय में अलग करने के लिए काफी सामान्य अभ्यास। विशेष रूप से एंटरप्राइज़ सिस्टम के लिए, सहायक पुस्तकालयों को परियोजनाओं में पुन: उपयोग करने के लिए यह एक सुविधाजनक तरीका है। (निजी एनपीएम में या सीधे निजी गिट पर होस्ट किया जा सकता है)।

पी.एस. मूल रूप से गिट सबमॉड्यूल आपकी सेवा को पुस्तकालय के रूप में होस्ट करने से वास्तव में अलग नहीं है। जब तक आप git के माध्यम से किसी अन्य प्रोजेक्ट से लिंक कर रहे हैं, और आपको इसे स्थापित करने और बनाने की आवश्यकता होगी। ठीक वही जो आप package.json फ़ाइल में निर्भरता रखते हुए कर रहे हैं।

समाधान #2: मोनोरेपो

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

निष्कर्ष

निर्णय लेना आपके द्वारा साझा किए जाने वाले कोड की मात्रा और इसकी जटिलता पर निर्भर होना चाहिए।

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

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

2
Mikki 31 अक्टूबर 2017, 01:04