2012-12-17 32 views
5

मैं एक नोड मॉड्यूल my-module विकसित कर रहा हूं जो बदले में दूसरे मॉड्यूल other-module पर निर्भर करता है। other-module इस प्रकार एक निर्भरता है जो स्पष्ट रूप से मेरे मॉड्यूल के पैकेज.जेसन में सूचीबद्ध है।नोड से कैसे बचें एक ही मॉड्यूल को दो बार लोड करने की आवश्यकता है

मेरी मॉड्यूल बस जा रहा है require घ द्वारा other-module के व्यवहार को संशोधित करता है के रूप में, यह महत्वपूर्ण है कि other-module केवल एक बार भरी हुई है और यह है कि, एक ही और 'उदाहरण' किसी भी आवेदन भर संदर्भित एक है कि दोनों my की आवश्यकता है और other

तो my-moduleother-module तो पहले npm install एड है बाद लाया जाता है:

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

तो my-modulenpm installe के बाद other-module तो मैं केवल एक node_modules में other-module की प्रतिलिपि अंत है और अपने परीक्षण एप्लिकेशन की उम्मीद के रूप में काम करता है।

यह व्यवहार मुझे नोड के प्रासंगिक नीतियों के माध्यम से फिर से देख हो गया और यकीन है कि पर्याप्त मैं 'मॉड्यूल कैशिंग चेतावनियां' में आए:

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

इस बिंदु पर ऐसा लगता है कि मेरा मॉड्यूल npm install एस के आदेश के आधार पर अपेक्षित व्यवहार कर सकता है या नहीं कर सकता है।

क्या कोई सर्वोत्तम प्रथा है जो मुझे याद आ रही है? क्या मेरे मॉड्यूल के तरीके को बदलने के बिना इस गड़बड़ी से बचने का कोई तरीका है?

उत्तर

4

संक्षिप्त उत्तर: आप नहीं कर सकते।

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

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

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

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

0

मुझे जेस्ट के साथ परीक्षण विकसित करते समय भी इसी तरह की समस्या थी।

निम्नलिखित बयान आप अलग संदर्भ में फिर से वही मॉड्यूल लोड करने के लिए अनुमति होगी:

jest.resetModules();