ब्रोकोली: पहला बीटा रिलीज़

ब्रोकली नया ऑटो-बिल्ड सिस्टम है। इसकी तुलना रेल परिसंपत्ति पाइपलाइन के साथ की जा सकती है, लेकिन कुछ अंतर हैं: यह Node.JS पर चलता है और यह एप्लिकेशन के सर्वर पक्ष पर निर्भर नहीं करता है।

0.0.x अल्फा रिलीज की एक लंबी स्ट्रिंग के बाद, मैंने सिर्फ पहला बीटा, ब्रोकोली 0.1.0 जारी किया।

सामग्री की तालिका:

1. त्वरित उदाहरण
2. प्रेरणा / सुविधाएँ
3. आर्किटेक्चर
4. पर्दे के पीछे / सामान्य रूप
5. अन्य बिल्ड सिस्टम के साथ तुलना
6. आगे क्या है?

1. त्वरित उदाहरण

निम्न बिल्ड (Brocfile.js) के लिए एक उदाहरण कॉन्फ़िगरेशन फ़ाइल है। टिप्पणियां जानबूझकर छोड़ी गई हैं, सिंटैक्स को चित्रित करने के लिए केवल एक उदाहरण प्रदान किया जाता है:

module.exports = function (broccoli) { var filterCoffeeScript = require('broccoli-coffee'); var compileES6 = require('broccoli-es6-concatenator'); var sourceTree = broccoli.makeTree('lib'); sourceTree = filterCoffeeScript(sourceTree); var appJs = compileES6(sourceTree, { ... outputFile: '/assets/app.js' }); var publicFiles = broccoli.makeTree('public'); return [appJs, publicFiles]; }; 

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

भागो broccoli build dist एक-बार बिल्ड बनाने के broccoli build dist करें और परिणाम को डिस्टर्ब फोल्डर में डालें।

अधिक विस्तृत उदाहरण के लिए, ब्रोकोली-नमूना-ऐप पर एक नज़र डालें

2. प्रेरणा / सुविधाएँ

2.1। त्वरित पुनर्निर्माण

ब्रोकोली डिजाइन का प्राथमिक फोकस तेज वृद्धिशील विधानसभाओं का कार्यान्वयन था। और यहाँ क्यों है:

उदाहरण के लिए, आप CoffeeScript, SASS, और कई अन्य पूर्वप्रक्रमकों में लिखे गए एप्लिकेशन के निर्माण के लिए ग्रंट का उपयोग करते हैं। जब आप कुछ विकसित कर रहे हैं, तो आप फ़ाइलों को संपादित करना चाहते हैं और तुरंत ब्राउज़र में परिणाम देखते हैं, बिना बिल्ड सिस्टम को लगातार लॉन्च किए। तो, इस प्रयोजन के लिए आप grunt watch उपयोग करते हैं, लेकिन जैसे-जैसे आपका एप्लिकेशन बढ़ता है, असेंबली धीमी और धीमी होती है। परियोजना पर कई महीनों के काम के बाद, आपका "संपादित-अद्यतन" चक्र "संपादित-प्रतीक्षित-10-सेकंड-अपडेट" में बदल जाता है।

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

ब्रोकोली के साथ, आप बस broccoli serve चला सकते broccoli serve , और वह समझ जाएगा कि किन फाइलों की निगरानी करने की आवश्यकता है, और केवल उन लोगों को फिर से बनाना होगा जिनकी इसे आवश्यकता है।

नतीजतन, इसका मतलब है कि पुनर्निर्माण, एक नियम के रूप में, ओ (1) निरंतर निष्पादन समय होना चाहिए, भले ही परियोजना में कितनी फ़ाइलों का उपयोग किया जाए, क्योंकि हमेशा सिर्फ एक के लिए जा रहा है। मैं प्रत्येक विधानसभा के लिए कार्यों के एक विशिष्ट सेट के साथ 200ms के परिणाम के लिए प्रयास करता हूं; चूंकि इस तरह की देरी का समय मानव मस्तिष्क के लिए लगभग तात्कालिक लगता है, तो मेरे लिए परिणाम आधे से एक सेकंड तक स्वीकार्य हैं।

2.2। प्लगइन्स चेन

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

 var tree = broccoli.makeTree('lib') tree = compileCoffeeScript(tree) tree = uglifyJS(tree) return tree 

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

3. वास्तुकला

उन लोगों के लिए जो विशेष रूप से उत्सुक हैं, मैं आपको ब्रोकोली वास्तुकला के बारे में बताता हूं।

3.1। पेड़, फाइलें नहीं

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

यदि ब्रोकोली ने अलग-अलग फ़ाइलों के साथ काम किया, तो हम अभी भी कॉफीस्क्रिप्ट को समस्याओं के बिना संकलित करने में सक्षम होंगे (क्योंकि फाइलें 1 से 1 के अनुसार संकलित की जाती हैं), हालांकि, यह एसएएस (जैसे कि आप का उपयोग करने की अनुमति देता है) के साथ एपीआई के साथ बातचीत करते समय समस्याएं पैदा करेगा। @import , जो आपको 1 में n फाइलें संकलित करने की अनुमति देता है)।

हालांकि, ब्रोकोली को इस तरह से डिज़ाइन किया गया है कि SASS (n: 1) जैसे प्रीप्रोसेसरों के लिए समस्याओं को हल करने से समस्याएँ पैदा नहीं होती हैं, और कॉफीस्क्रिप्ट (1: 1) जैसे प्रीप्रोसेसरों के लिए कार्य आसानी से n: 1 के विशेष मामले के रूप में हल हो जाते हैं। सामान्य तौर पर, इस तरह के (1: 1) परिवर्तनों के लिए, हमारे पास Filter क्लास है, जो हमारे निर्णयों में उनका उपयोग करना यथासंभव सरल बनाता है।

3.2। प्लगइन्स सिर्फ नए पेड़ लौटाते हैं

सबसे पहले, मैंने ब्रोकोली को दो प्राइमेटीज़ के साथ डिज़ाइन किया: tree (इसके बाद "ट्री" के रूप में संदर्भित), जो फ़ाइलों और transform साथ निर्देशिकाओं का प्रतिनिधित्व करता है (बाद में transform "ट्रांसफॉर्मेशन" transform है), जो इनपुट पर एक ट्री लेता है और ट्रांसफॉर्मेशन के बाद आउटपुट पर एक नया, संकलित ट्री देता है।

इसका अर्थ है कि हम पेड़ों को 1: 1 में बदल देते हैं। हैरानी की बात है, यह हमेशा एक अच्छा अमूर्त नहीं है। उदाहरण के लिए, SASS में "डाउनलोड पथ" हैं जिनका उपयोग @import निर्देश का उपयोग करके फ़ाइलों को खोजने के लिए किया जाता है। एक समान सिद्धांत द्वारा r.js की तरह काम करने वाले: यह विकल्प "पथ" है, जो आयातित मॉड्यूल खोजने के लिए जिम्मेदार है। इन रास्तों का प्रतिनिधित्व करने का सबसे अच्छा तरीका पेड़ों से बना एक सेट (डेटा संरचना) है।

जैसा कि आप देख सकते हैं, वास्तविक दुनिया में, कई कंपाइलर / प्रीप्रोसेसर एक में n "पेड़ों" को इकट्ठा करते हैं। इस दृष्टिकोण का अनुसरण करने का सबसे आसान तरीका प्लगइन्स को अपने इनपुट "पेड़ों" से निपटने की अनुमति देना है, जिससे उन्हें इनपुट के लिए 0, 1 या n "पेड़ों" को स्वीकार करने की अनुमति मिलती है।

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

 broccoli.makeTree('lib') // => a tree compileCoffeeScript(tree) // => a tree compileSass(tree, { loadPaths: [moreTrees, ...] }) // => a tree 

3.3। फाइल सिस्टम हमारा एपीआई है

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

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

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

Fs Node.JS मॉड्यूल पहले से ही एपीआई प्रदान करता है जो हमें फ़ाइल सिस्टम के लिए आवश्यक है - हम सभी के लिए इच्छा कर सकते हैं।

केवल असुविधा यह है कि हमें "दृश्यों के पीछे" अस्थायी निर्देशिकाओं के साथ काम करना होगा, और फिर हमें चुस्त-दुरुस्त करने की आवश्यकता होगी। लेकिन, वास्तव में, यह उतना मुश्किल नहीं है जितना लगता है।

लोगों को कभी-कभी चिंता होती है कि डिस्क पर लिखना स्मृति की तुलना में धीमा है। लेकिन यहां तक ​​कि अगर आप एक हार्ड ड्राइव लेते हैं, तो आधुनिक एसएसडी का थ्रूपुट इतना अधिक हो जाता है कि इसकी तुलना सीपीयू की गति के साथ की जा सकती है, जिसका अर्थ है कि हमें केवल निरर्थक ओवरहेड्स मिलते हैं।

3.4। आंशिक पुनर्निर्माण के बजाय कैशिंग

जब मैंने वृद्धिशील निर्माण समस्या को हल करने की कोशिश की, तो मैंने यह जांचने के लिए एक तरीका तैयार करने की कोशिश की कि कौन सी फाइलों को फिर से बनाने की जरूरत है, ताकि ब्रोकली को इस घटना को स्रोत फ़ाइलों के सबसेट के लिए बढ़ाने की अनुमति मिल सके। वृद्धिशील बिल्ड में, हमें यह जानना होगा कि परिणाम किस स्रोत पर निर्भर करता है क्योंकि हम अक्सर n: 1 रिश्तों का सामना करते हैं। आंशिक विधानसभा क्लासिक मेक अप्रोच है, साथ ही रेल संपत्ति पाइपलाइन, रेक :: पाइपलाइन या ब्रंच है, लेकिन मैंने व्यक्तिगत रूप से खुद के लिए फैसला किया है कि ये अनावश्यक कठिनाइयां हैं।

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

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

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

3.5। कोई समानता नहीं

यदि हम सभी धीमे निर्माण से पीड़ित हैं, तो शायद आपको समानांतर में कार्यों को पूरा करने की कोशिश करनी चाहिए?

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

दूसरी ओर, समानांतर लॉन्च का उपयोग करने पर अमदाल का नियम हमें शानदार प्रदर्शन करने से रोकता है। आइए एक सरल उदाहरण दें: हमारी विधानसभा में 16 सेकंड लगते हैं। कल्पना करें कि हम समानांतर में 50% चला सकते हैं, और बाकी को कतार के क्रम में चलाया जाना चाहिए (एक ला कॉफी-> संक्षिप्त -> बदसूरत)। यदि हम इस तरह की असेंबली को क्वाड-कोर मशीन पर चलाते हैं, तो असेंबली में 10 सेकंड का समय लगेगा: सिंक्रोनस भाग के लिए 8 सेकंड, और समानांतर भाग के लिए 8/4 = 2 सेकंड। नतीजतन, निर्माण का समय अभी भी 10 सेकंड जितना है, और यह उत्पादकता का केवल + 40% है।

वृद्धिशील के लिए कि ब्याज हमें सबसे अधिक बनाता है, कैशिंग समानांतर में चल रहे कार्यों के अधिकांश लाभों को कम करता है, इसलिए हम लगभग प्रदर्शन नहीं खोते हैं।

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

4. पर्दे के पीछे / सामान्य रूप

एक अच्छी बिल्ड सिस्टम लिखने का मेरा निर्णय दो कारणों पर आधारित है।

पहला कारण वृद्धिशील बिल्ड द्वारा प्राप्त बेहतर प्रदर्शन है।

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

दूसरा कारण फ्रंट-एंड पैकेजों के पारिस्थितिक तंत्र का समर्थन करना है।

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

वैसे, ब्रोकोली खुद किसी भी तरह से बोवर या ईएस 6 मॉड्यूल के साथ नहीं जुड़ा हुआ है - आप इसका उपयोग कर सकते हैं जो आप चाहते हैं। (मुझे पता है कि अन्य बंडल हैं, उदाहरण के लिए npm + browserify, या npm + r.js.) मैं उन्हें अपनी अगली पोस्ट में शामिल करूंगा।

5. अन्य बिल्ड सिस्टम के साथ तुलना

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

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

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

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

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

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

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

6. आगे क्या है

प्लगइन्स की सूची अभी भी छोटी है। लेकिन अगर यह आपके कार्यों के लिए पर्याप्त है, तो मैं ब्रोकली को एक मौका देने की जोरदार सलाह दूंगा: https://github.com/joliss/broccoli#installation

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

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

जल्द ही आप एम्बर ढांचे के पारिस्थितिकी तंत्र में ब्रोकोली का सक्रिय उपयोग देख पाएंगे, जो डिफ़ॉल्ट एम्बर-क्ली स्टैक प्रदान करेगा (जल्द ही दिखाई देगा, रेलिंग कमांड लाइन की कार्यक्षमता के समान)। हम रेक को बदलने की उम्मीद भी करते हैं: एम्बर कर्नेल बिल्ड प्रक्रिया के दौरान पाइपलाइन और ग्रंट।

मैं वास्तव में ब्रोकोली को एम्बर समुदाय के बाहर की परियोजनाओं के लिए अनुकूलित देखना भी चाहूंगा। जेएस एमवीसी अनुप्रयोगों को एंगुलर या बैकबोन, विभिन्न जेएस और सीएसएस पुस्तकालयों जैसे कि असेंबली की आवश्यकता होती है, ब्रोकोली का उपयोग करके बनाए जाने वाले मुख्य उम्मीदवार हैं। वास्तविक बिल्ड परिदृश्यों के लिए ब्रोकोली का उपयोग करना, हमें यह सुनिश्चित करने की आवश्यकता है कि इसका एपीआई विश्वसनीय है, और मुझे उम्मीद है कि अगले कुछ महीनों में हम पहला स्थिर (1.0.0) संस्करण जारी कर पाएंगे।

यह पोस्ट ब्रोकोली वास्तुकला का विस्तार करने वाली पहली पोस्ट है, इसलिए अभी भी बहुत कम मदद / प्रलेखन है। मुझे आपकी मदद करने में खुशी होगी, और आपके द्वारा सामना किए जाने वाले किसी भी कीड़े को ठीक करने में मदद मिलेगी। आप मुझे Freenode पर #broccolijs पर पा सकते हैं, या मुझे एक ईमेल लिख सकते हैं / Google Talk: joliss42/mail.com पर कॉल कर सकते हैं।मुझे जीथब पर संबंधित अनुभाग में आपके किसी भी प्रश्न का उत्तर देने में खुशी होगी ।

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

अनुवादक से

मैं इस अनुवाद को सही करने में उनकी मदद के लिए z6Dabrata और मारिया कुज़ोवचिकोवा को धन्यवाद देना चाहूंगा ।