हैलो, मेरा नाम दिमित्री कार्लोव्स्की है, और मैं ... मैम को मानता हूं। M AM, Gnostic M moduli को नियमित करता है, जिससे मुझे शेरों की दिनचर्या की बचत होती है।

ठेठ अज्ञेय मॉड्यूल

एक अज्ञेय मॉड्यूल , पारंपरिक एक के विपरीत, एक स्रोत के साथ एक फ़ाइल नहीं है, लेकिन एक निर्देशिका है जिसके अंदर विभिन्न भाषाओं में स्रोत हो सकते हैं: JS / TS में कार्यक्रम तर्क, TS / JS में इसके लिए परीक्षण, view.tree में view.tree घटकों की रचना, शैलियों CSS , locale=*.json में लोकेशन locale=*.json , images इत्यादि। यदि वांछित है, तो किसी अन्य भाषा के समर्थन को जकड़ना मुश्किल नहीं है। उदाहरण के लिए, स्टाइल लिखने के लिए स्टाइलस, या टेम्पलेट का वर्णन करने के लिए HTML।

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

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

दर्शन

MAM कोड को व्यवस्थित करने और इसके साथ काम करने की प्रक्रिया को मौलिक रूप से बदलने के लिए एक साहसिक प्रयोग है। यहाँ मूल सिद्धांत हैं:

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

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

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

न्यूनतम अनावश्यक कोड। मॉड्यूल में कोड को तोड़ना एक फ़ाइल में सभी कोड लिखने के समान सरल होना चाहिए। अन्यथा, डेवलपर बड़े मॉड्यूल को छोटे लोगों में तोड़ने के लिए आलसी होगा।

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

नाड़ी पर उंगली रखें। असंगतताओं के बारे में सबसे तेज़ प्रतिक्रिया कोड को खराब नहीं होने देगी।

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

आयात / निर्यात

हम एक आधुनिक मॉड्यूल सिस्टम का उपयोग करके पहली परियोजना को खोलते हैं: एक मॉड्यूल 300 लाइनों से कम लंबा होता है, जिनमें से 30 आयात होते हैं।

लेकिन ये अभी भी फूल हैं: 9 लाइनों के एक समारोह के लिए, 8 आयात की आवश्यकता होती है।

और मेरा पसंदीदा: उपयोगी कोड की एक भी पंक्ति नहीं। मॉड्यूल के ढेर से मूल्यों को एक में स्थानांतरित करने की 20 लाइनें, ताकि बाद में आप एक मॉड्यूल से आयात कर सकें, और बीस से नहीं।

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

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

विचार: क्या होगा यदि हम आयात नहीं करते हैं, लेकिन बस लेते हैं और उपयोग करते हैं, और कलेक्टर स्वयं यह पता लगाएगा कि क्या आयात करने की आवश्यकता है?

आधुनिक आईडीई स्वचालित रूप से आपके द्वारा उपयोग की जाने वाली संस्थाओं के लिए आयात उत्पन्न कर सकता है। अगर आईडीई ऐसा कर सकता है, तो कलेक्टर को ऐसा करने से क्या रोकता है? फ़ाइलों के नामकरण और स्थान पर एक साधारण सम्मेलन होना पर्याप्त है, जो उपयोगकर्ता के लिए सुविधाजनक होगा और मशीन के लिए समझ में आएगा। PHP में लंबे समय से इस तरह का एक मानक सम्मेलन है: PSR-4 । MAM .ts और .jam.js फ़ाइलों के लिए समान परिचय देता है: $ के साथ शुरू होने वाले नाम कुछ वैश्विक इकाई के पूरी तरह से योग्य नाम हैं जिनके कोड को FQN से प्राप्त पथ के साथ परिसीम को स्लैश से प्रतिस्थापित किया जाता है। दो मॉड्यूल का एक सरल उदाहरण:

मेरे / सतर्क / सतर्क

 const $my_alert = alert // FQN

my / app / app.ts

 $my_alert( 'Hello!' ) // ,   /my/alert/

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

एक अच्छा उदाहरण सत्यापन मॉड्यूल के JSON / mol / डेटा परिवार है। यदि आप $mol_data_integer फ़ंक्शन का उपयोग अपने कोड में कहीं करते हैं, तो मॉड्यूल /mol/data/integer और /mol/data/number , जिस पर $mol_data_integer निर्भर करता है, को बंडल में शामिल किया जाएगा। लेकिन, उदाहरण के लिए, कलेक्टर /mol/data/email डिस्क से भी नहीं पढ़ेगा, क्योंकि कोई भी इस पर निर्भर नहीं करता है।

गड़बड़ी करना

चूँकि हमने कोणीय को मारना शुरू कर दिया था, हम नहीं रुकेंगे। आप applyStyles समारोह applyStyles लिए कहां देखना चाहते हैं? आपने / /packages/core/src/render3/styling_next/bindings.ts / /packages/core/src/render3/styling_next/bindings.ts / /packages/core/src/render3/styling_next/bindings.ts / /packages/core/src/render3/styling_next/bindings.ts / /packages/core/src/render3/styling_next/bindings.ts / /packages/core/src/render3/styling_next/bindings.ts पर अनुमान नहीं /packages/core/src/render3/styling_next/bindings.ts । कहीं भी कुछ भी रखने की क्षमता इस तथ्य की ओर ले जाती है कि प्रत्येक परियोजना में हम एक अद्वितीय फ़ाइल स्थान प्रणाली का निरीक्षण करते हैं, अक्सर किसी भी तर्क के लिए उत्तरदायी नहीं। और अगर आईडीई को अक्सर "परिभाषा के लिए कूद" से बचाया जाता है, तो जीथब पर कोड देखने या पुल अनुरोध की समीक्षा करने से इस अवसर से वंचित हो जाते हैं।

विचार: क्या होगा यदि संस्था के नाम उनके स्थान के अनुरूप हैं?

फ़ाइल को /angular/packages/core/src/render3/stylingNext/bindings.ts में कोड /angular/packages/core/src/render3/stylingNext/bindings.ts , MAM आर्किटेक्चर में आपको इकाई का नाम $angular_packages_core_src_render3_stylingNext_applyStyles , लेकिन निश्चित रूप से, कोई भी कार्य नहीं करेगा, क्योंकि कोई भी कार्य नहीं करेगा। लेकिन कोड में नाम मैं छोटा और संक्षिप्त देखना चाहता हूं, इसलिए डेवलपर नाम से सभी अनावश्यक को बाहर करने की कोशिश करेगा, केवल महत्वपूर्ण छोड़कर: $angular_render3_applyStyles । और यह /angular/render3/applyStyles/applyStyles.ts अनुसार स्थित होगा।

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

 73ebc45e517ffcc3dcce53f5b39b6d06fc95cae1 $mol_vector: range expanding support 3a843b2cb77be19688324eeb72bd090d350a6cc3 $mol_data: allowed transformations 24576f087133a18e0c9f31e0d61052265fd8a31a $mol_data_record: support recursion

या, मान लें कि आप इंटरनेट पर $ mol_fiber मॉड्यूल के सभी उल्लेखों को खोजना चाहते हैं - FQN के लिए पहले से कहीं अधिक आसान धन्यवाद।

चक्रीय निर्भरता

आइए एक फाइल में सरल कोड की 7 पंक्तियां लिखें:

 export class Foo { get bar() { return new Bar(); } } export class Bar extends Foo {} console.log(new Foo().bar);

चक्रीय निर्भरता के बावजूद, यह सही ढंग से काम करता है। हम इसे 3 फाइलों में तोड़ देते हैं:

मेरी / foo.js

 import { Bar } from './bar.js'; export class Foo { get bar() { return new Bar(); } }

my / bar.js

 import { Foo } from './foo.js'; export class Bar extends Foo {}

मेरी / app.js

 import { Foo } from './foo.js'; console.log(new Foo().bar);

ओह, ReferenceError: Cannot access 'Foo' before initialization । यह कैसी बकवास है? इसे ठीक करने के लिए, हमारे app.js को यह जानना होगा कि foo.js पर निर्भर करता है इसलिए, हमें पहले bar.js आयात करने की आवश्यकता है, जो foo.js जिसके बाद हम पहले से ही त्रुटि के बिना foo.js आयात कर सकते हैं:

मेरी / app.js

 import './bar.js'; import { Foo } from './foo.js'; console.log(new Foo().bar);

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

विचार: क्या होगा यदि असेंबली के दौरान हम फाइलों को सही क्रम में गोंद दें, जैसे कि सभी कोड मूल रूप से एक फाइल में लिखे गए हों?

मैम के सिद्धांतों का उपयोग करते हुए कोड को विभाजित करें:

my / foo / foo.ts

 class $my_foo { get bar() { return new $my_bar(); } }

my / bar / bar.ts

 class $my_bar extends $my_foo {}

my / app / app.ts

 console.log(new $my_foo().bar);

कोड के सभी समान 7 लाइनें जो मूल रूप से थीं। और वे सिर्फ अतिरिक्त shamanism के बिना काम करते हैं। बात यह है कि कलेक्टर समझता है कि my/bar पर my/foo my/bar की निर्भरता my/bar पर my/foo अधिक कठोर है। इसका मतलब है कि आपको इन मॉड्यूल को बंडल में इस क्रम में शामिल करना चाहिए: my/foo , my/bar , my/app ।

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

विभिन्न भाषाओं

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

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

 .dark-theme table { background: black; } .light-theme table { background: white; }

इसके अलावा, यदि हम विषय पर निर्भर हैं, तो एक स्क्रिप्ट लोड की जानी चाहिए जो दिन के समय के आधार पर वांछित विषय को स्थापित करेगी। अर्थात्, CSS वास्तव में JS पर निर्भर करता है।

विचार: क्या होगा यदि एक मॉड्यूलर प्रणाली भाषाओं पर निर्भर न हो?

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

/my/table/table.css

 /* ,   /my/theme */ [my_theme="dark"] table { background: black; } [my_theme="light"] table { background: white; }

/my/theme/theme.js

 document.documentElement.setAttribute( 'my_theme' , ( new Date().getHours() + 15 ) % 24 < 12 ? 'light' : 'dark' , )

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

कई पुस्तकालय

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

विचार: क्या होगा यदि किसी भी मॉड्यूल को प्रारंभिक तैयारी के बिना एक स्वतंत्र बंडल में इकट्ठा किया जा सकता है?

आइए, $ mol_build MAM प्रोजेक्ट बिल्डर के नवीनतम संस्करण को एक साथ रखते हैं:

 mam mol/build

अब इस कलेक्टर को चलाएं और उसे खुद को फिर से इकट्ठा करने दें ताकि यह सुनिश्चित हो सके कि वह अभी भी खुद को इकट्ठा करने में सक्षम है:

 node mol/build/-/node.js mol/build

हालाँकि, नहीं, चलो उसे विधानसभा के साथ परीक्षण चलाने के लिए कहें:

 node mol/build/-/node.test.js mol/build

और अगर सब कुछ ठीक रहा, तो एनपीएम में परिणाम प्रकाशित करें:

 npm publish mol/build/-

जैसा कि आप देख सकते हैं, मॉड्यूल को इकट्ठा करते समय, नाम के साथ एक उपनिर्देशिका बनाई जाती है - और सभी विधानसभा कलाकृतियों को वहां रखा जाता है। आइए उन फ़ाइलों के माध्यम से जाएं जो आप वहां पा सकते हैं:

web.dep.json - निर्भरता ग्राफ के बारे में सभी जानकारी
web.js - ब्राउज़र स्क्रिप्ट बंडल
web.js.map - उसके लिए sorsmaps
web.esm.js - यह एक ईएस-मॉड्यूल के रूप में है
web.esm.js.map - और इसके लिए sorsmaps
web.test.js - परीक्षण बंडल
web.test.js.map - और सॉर्समैप परीक्षणों के लिए
web.d.ts - स्क्रिप्ट बंडल में सब कुछ के प्रकार के साथ बंडल
web.css - शैलियों के साथ बंडल
web.css.map - और इसके लिए संक्षिप्त नाम
web.test.html - एक ब्राउज़र में प्रदर्शन परीक्षण चलाने के लिए प्रवेश बिंदु
web.view.tree - बंडल web.view.tree में शामिल सभी घटकों की घोषणा
web.locale=*.json - स्थानीय पाठों के साथ बंडल, प्रत्येक बंडल का अपना बंडल होता है
package.json - आपको NPM में इकट्ठे मॉड्यूल को तुरंत प्रकाशित करने की अनुमति देता है
node.dep.json - निर्भरता ग्राफ के बारे में सभी जानकारी
node.js - नोड स्क्रिप्टिंग बंडल
node.js.map - इसके लिए सॉर्समैप
node.esm.js - यह एक ईएस-मॉड्यूल के रूप में है
node.esm.js.map - और इसके लिए सॉर्समैप
node.test.js - एक ही बंडल, लेकिन परीक्षणों के साथ भी
node.test.js.map - और इसके लिए सॉर्समैप
node.d.ts - स्क्रिप्ट बंडल में सब कुछ के प्रकार के साथ बंडल
node.view.tree - बंडल node.view.tree में शामिल सभी घटकों की घोषणाएं
node.locale=*.json - स्थानीय ग्रंथों के साथ बंडल, प्रत्येक बंडल का अपना बंडल होता है

स्टैटिक्स को केवल रास्तों के साथ कॉपी किया जाता है। एक उदाहरण के रूप में, एक एप्लिकेशन लें जो अपने स्वयं के स्रोत कोड प्रदर्शित करता है । इसके स्रोत यहां हैं:

/mol/app/quine/quine.view.tree
/mol/app/quine/quine.view.ts
/mol/app/quine/index.html
/mol/app/quine/quine.locale=ru.json

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

/mol/app/quine/quine.meta.tree

 deploy \/mol/app/quine/quine.view.tree deploy \/mol/app/quine/quine.view.ts deploy \/mol/app/quine/index.html deploy \/mol/app/quine/quine.locale=ru.json

असेंबली /mol/app/quine , उन्हें निम्नलिखित तरीकों से कॉपी किया जाएगा:

/mol/app/quine/-/mol/app/quine/quine.view.tree
/mol/app/quine/-/mol/app/quine/quine.view.ts
/mol/app/quine/-/mol/app/quine/index.html
/mol/app/quine/-/mol/app/quine/quine.locale=ru.json

अब निर्देशिका /mol/app/quine/- को किसी भी स्थैतिक होस्टिंग पर रखा जा सकता है और आवेदन पूरी तरह कार्यात्मक होगा।

प्लेटफार्मों को लक्षित करें

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

विचार: क्या होगा यदि फ़ाइल का उद्देश्य इसके नाम से परिलक्षित होता है?

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

/ mol / state / arg / arg। वेब .ts - ब्राउज़रों के लिए कार्यान्वयन
/ mol / state / arg / arg। नोड .ts - एक नोड के लिए कार्यान्वयन

इन टैग के साथ टैग नहीं किए गए स्रोत लक्ष्य प्लेटफ़ॉर्म की परवाह किए बिना शामिल किए गए हैं।

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

/ mol / state / arg / arg। परीक्षण .ts - मॉड्यूल परीक्षण, वे परीक्षण बंडल में गिर जाएंगे

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

/ mol / app / जीवन / जीवन। locale = ru .json - रूसी भाषा के लिए ग्रंथ
/ mol / app / जीवन / जीवन। locale = jp .json - जापानी के लिए ग्रंथ

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

/ hyoo / खिलौने / । git - एक अवधि से शुरू होता है, इसलिए कलेक्टर इस निर्देशिका को अनदेखा करेगा

वर्ज़निंग

Google ने पहले AngularJS जारी किया और इसे NPM में angular रूप में प्रकाशित किया। फिर उसने एक समान नाम के साथ एक पूरी तरह से नया ढांचा बनाया - कोणीय और इसे उसी नाम से प्रकाशित किया, लेकिन पहले से ही संस्करण 2. अब ये दो आतिशबाजी स्वतंत्र रूप से विकसित हो रहे हैं। प्रमुख संस्करणों के बीच केवल एक एपीआई-ब्रेकिंग परिवर्तन होता है। और दूसरा - नाबालिग के बीच । और चूंकि एक ही निर्भरता के दो संस्करणों को एक ही स्तर पर रखना असंभव है, इसलिए आवेदन में कुछ समय के लिए लाइब्रेरी के दो संस्करणों में किसी भी सहज संक्रमण की बात नहीं हो सकती है।

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

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

लेकिन लॉक फाइलों का क्या? यदि आप एक पुस्तकालय विकसित कर रहे हैं जो निर्भरता के माध्यम से स्थापित है, तो लॉक फ़ाइल आपकी मदद नहीं करेगी, क्योंकि इसे पैकेज प्रबंधक द्वारा अनदेखा किया जाएगा। अंतिम आवेदन के लिए, लॉक फ़ाइल आपको तथाकथित "असेंबली की पुनरुत्पत्ति" देगी। लेकिन चलो ईमानदार हो। एक ही स्रोत से अंतिम आवेदन बनाने के लिए आपको कितनी बार चाहिए? बिल्कुल एक बार। आउटपुट प्राप्त करना, किसी भी एनपीएम से स्वतंत्र, असेंबली आर्टवर्क: एक निष्पादन योग्य बाइनरी, डॉक कंटेनर या इसे चलाने के लिए आवश्यक सभी कोड के साथ एक संग्रह। मुझे आशा है कि आप npm install नहीं कर रहे हैं ठेस पर?

कुछ ताला फ़ाइलों का उपयोग करने के लिए CI सर्वर है कि डेवलपर क्या प्रतिबद्ध है इकट्ठा। लेकिन रुकिए, डेवलपर खुद ही इसे अपने स्थानीय मशीन पर इकट्ठा कर सकता है। , , , . Continuous Integration , , , , - . CI , .

, , . , Angular@4 ( 3). , , " " " ". Angular@4 , Angular@5. Angular@6, . Angular TypeScript . . , 2 , … , business value , , , , .

, , , , 2 . : , — , — . 3 React, 5 jQuery, 7 lodash.

: — ?

. - . , . , . , . , . , . , , . : issue, , workaround, pull request, , . , , . . .

, . , , . . . : , , -. - — . , , - . , , , NPM . , . .

, ? — . mobx , mobx2 API . — , : , . mobx mobx2 , API. API, .

. — . , :

 var pages_count = $mol_atom2_sync( ()=> $lib_pdfjs.getDocument( uri ).promise ).document().numPages

mol_atom2_sync lib_pdfjs , :

 npm install mol_atom2_sync@2.1 lib_pdfjs@5.6

, , — , . ? — , *.meta.tree , :

/.meta.tree

 pack node git \https://github.com/nin-jin/pms-node.git pack mol git \https://github.com/eigenmethod/mol.git pack lib git \https://github.com/eigenmethod/mam-lib.git

. .

NPM

MAM — NPM . , — . , , NPM .

NPM , $node. , - -:

/my/app/app.ts

 $node.portastic.find({ min : 8080 , max : 8100 , retrieve : 1 }).then( ( ports : number[] ) => { $node.express().listen( ports[0] ) })

, . - lib NPM . , NPM- pdfjs-dist :

/lib/pdfjs/pdfjs.ts

 namespace $ { export let $lib_pdfjs : typeof import( 'pdfjs-dist' ) = require( 'pdfjs-dist/build/pdf.min.js' ) $lib_pdfjs.disableRange = true $lib_pdfjs.GlobalWorkerOptions.workerSrc = '-/node_modules/pdfjs-dist/build/pdf.worker.min.js' }

/lib/pdfjs/pdfjs.meta.tree

 deploy \/node_modules/pdfjs-dist/build/pdf.worker.min.js

, .

. create-react-app angular-cli , . , , eject . . , , .

: ?

MAM . .

MAM MAM , :

 git clone https://github.com/eigenmethod/mam.git ./mam && cd mam npm install npm start

8080 . , — MAM.

( — acme ) ( — hello home ):

/acme/acme.meta.tree

 pack hello git \https://github.com/acme/hello.git pack home git \https://github.com/acme/home.git

npm start :

 npm start acme/hello acme/home

. — . , , . — : https://t.me/mam_mol

MAM: दर्द के बिना विधानसभा सामने