पेश है सीएलआई बिल्डर

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

कहानी

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

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

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

इस तथ्य के बावजूद कि आर्किटेक्ट को आधिकारिक रूप से समर्थन नहीं मिला था, यह डेवलपर्स के बीच लोकप्रिय था जो परियोजनाओं की विधानसभा को अनुकूलित करना चाहते थे, साथ ही साथ तीसरे पक्ष के पुस्तकालयों के बीच जो कि उनके वर्कफ़्लो को नियंत्रित करने के लिए आवश्यक थे। Nx ने इसका उपयोग Bazel कमांड को निष्पादित करने के लिए किया, Ionic ने इसका उपयोग जेस्ट पर यूनिट टेस्ट चलाने के लिए किया, और उपयोगकर्ता ngx-build-plus जैसे टूल का उपयोग करके अपने वेबपैक कॉन्फ़िगरेशन को बढ़ा सकते हैं। और यह सिर्फ शुरुआत थी।

इस एपीआई के आधिकारिक तौर पर समर्थित, स्थिर और बेहतर संस्करण का उपयोग कोणीय सीएलआई संस्करण 8 में किया जाता है।

संकल्पना

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

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

कलेक्टरों

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

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

कार्यक्षेत्र फ़ाइल और कार्य

आर्किटेक्ट एपीआई कोणीय.जेसन पर निर्भर करता है, जो कार्य और उनकी सेटिंग्स को संग्रहीत करने के लिए एक कार्यक्षेत्र फ़ाइल है।

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

1. बिल्डर - कार्य को पूरा करने के लिए उपयोग करने के लिए कलेक्टर का नाम, PACKAGE_NAME प्रारूप में : ASSEMBLY_NAME ।
2. विकल्प - डिफ़ॉल्ट रूप से कार्य शुरू करते समय उपयोग की जाने वाली सेटिंग्स।
3. कॉन्फ़िगरेशन - सेटिंग्स जो निर्दिष्ट कॉन्फ़िगरेशन के साथ कार्य शुरू करते समय लागू की जाएंगी।

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

कार्यक्षेत्र की अधिक जानकारी यहाँ ।

अपना खुद का कलेक्टर बनाएं

एक उदाहरण के रूप में, आइए एक कलेक्टर बनाएं जो कमांड लाइन पर एक कमांड चलाएगा। एक कलेक्टर बनाने के लिए, CreateBuilder फैक्ट्री का उपयोग करें और BuilderOutput ऑब्जेक्ट वापस करें:

import { BuilderOutput, createBuilder } from '@angular-devkit/architect'; export default createBuilder((options, context) => { return new Promise<BuilderOutput>(resolve => { resolve({ success: true }); }); }); 

अब, अपने संग्राहक में कुछ तर्क जोड़ते हैं: हम कलेक्टर को सेटिंग्स के माध्यम से नियंत्रित करना चाहते हैं, नई प्रक्रियाएँ बनाते हैं, प्रक्रिया पूरी होने तक प्रतीक्षा करते हैं, और यदि प्रक्रिया सफलतापूर्वक पूरी हो जाती है (अर्थात, कोड 0 लौटाते हैं), इसे आर्किटेक्ट को संकेत दें:

 import { BuilderOutput, createBuilder } from '@angular-devkit/architect'; import * as childProcess from 'child_process'; export default createBuilder((options, context) => { const child = childProcess.spawn(options.command, options.args); return new Promise<BuilderOutput>(resolve => { child.on('close', code => { resolve({ success: code === 0 }); }); }); }); 

आउटपुट प्रसंस्करण

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

ऐसा करने के लिए, हम लॉगर का उपयोग कर सकते हैं, जो संदर्भ ऑब्जेक्ट में उपलब्ध है, जो हमें प्रक्रिया के आउटपुट को रीडायरेक्ट करने की अनुमति देगा:

 import { BuilderOutput, createBuilder } from '@angular-devkit/architect'; import * as childProcess from 'child_process'; export default createBuilder((options, context) => { const child = childProcess.spawn(options.command, options.args, { stdio: 'pipe' }); child.stdout.on('data', (data) => { context.logger.info(data.toString()); }); child.stderr.on('data', (data) => { context.logger.error(data.toString()); }); return new Promise<BuilderOutput>(resolve => { child.on('close', code => { resolve({ success: code === 0 }); }); }); }); 

प्रदर्शन और स्थिति रिपोर्ट

अपने खुद के कलेक्टर के कार्यान्वयन से संबंधित एपीआई का अंतिम हिस्सा प्रगति और वर्तमान स्थिति रिपोर्ट है।

हमारे मामले में, कमांड या तो पूरा हो गया है या निष्पादित हो गया है, इसलिए यह प्रगति रिपोर्ट जोड़ने के लिए कोई मतलब नहीं है। हालाँकि, हम अपनी स्थिति को पैरेंट कलेक्टर को बता सकते हैं ताकि वह समझ सके कि क्या हो रहा है।

 import { BuilderOutput, createBuilder } from '@angular-devkit/architect'; import * as childProcess from 'child_process'; export default createBuilder((options, context) => { context.reportStatus(`Executing "${options.command}"...`); const child = childProcess.spawn(options.command, options.args, { stdio: 'pipe' }); child.stdout.on('data', (data) => { context.logger.info(data.toString()); }); child.stderr.on('data', (data) => { context.logger.error(data.toString()); }); return new Promise<BuilderOutput>(resolve => { context.reportStatus(`Done.`); child.on('close', code => { resolve({ success: code === 0 }); }); }); }); 

प्रगति रिपोर्ट पास करने के लिए, दलीलों के रूप में करंट और (वैकल्पिक रूप से) सारांश मूल्यों के साथ ReportProgress विधि का उपयोग करें। कुल कोई भी संख्या हो सकती है। उदाहरण के लिए, यदि आप जानते हैं कि आपको कितनी फ़ाइलों को संसाधित करने की आवश्यकता है, तो आप उनकी संख्या को कुल में स्थानांतरित कर सकते हैं, फिर वर्तमान में आप पहले से संसाधित फ़ाइलों की संख्या को स्थानांतरित कर सकते हैं। यह कैसे tslint कलेक्टर इसकी प्रगति पर रिपोर्ट करता है।

इनपुट सत्यापन

कलेक्टर को दिए गए विकल्प ऑब्जेक्ट को JSON स्कीमा का उपयोग करके जांचा जाता है। यह स्कैमेटिक्स के समान है यदि आप जानते हैं कि यह क्या है।

हमारे कलेक्टर उदाहरण में, हम उम्मीद करते हैं कि हमारे पैरामीटर एक ऑब्जेक्ट होंगे जो दो कुंजी प्राप्त करता है: कमांड - कमांड (स्ट्रिंग) और आर्ग्स - तर्क (स्ट्रिंग का सरणी)। हमारी सत्यापन योजना इस तरह दिखाई देगी:

 { "$schema": "http://json-schema.org/schema", "type": "object", "properties": { "command": { "type": "string" }, "args": { "type": "array", "items": { "type": "string" } } } 

योजनाएं वास्तव में शक्तिशाली उपकरण हैं जो बड़ी संख्या में जांच कर सकते हैं। JSON योजनाओं के बारे में अधिक जानकारी के लिए, आप आधिकारिक JSON स्कीमा वेबसाइट को देख सकते हैं।

एक बिल्ड पैकेज बनाएँ

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

 { "builders": { "command": { "implementation": "./command", "schema": "./command/schema.json", "description": "Runs any command line in the operating system." } } } 

फिर, package.json फ़ाइल में, हम बिल्डरों को जोड़ते हैं, builders.json फ़ाइल की ओर इशारा करते हुए:

 { "name": "@example/command-runner", "version": "1.0.0", "description": "Builder for Architect", "builders": "builders.json", "devDependencies": { "@angular-devkit/architect": "^1.0.0" } } 

यह आर्किटेक्ट को बताएगा कि कलेक्टर की परिभाषा फ़ाइल को कहां देखना है।

इस प्रकार, हमारे कलेक्टर का नाम "@ उदाहरण / कमांड-रनर: कमांड" है । बृहदान्त्र से पहले नाम का पहला भाग (:) पैकेज का नाम है, जिसे पैकेज का उपयोग करके परिभाषित किया गया है। दूसरा भाग, कलेक्टर का नाम है, जिसे बिल्डरों के नाम से परिभाषित किया गया है। जेसन फ़ाइल।

अपने खुद के बिल्डरों का परीक्षण

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

पैटर्न को सरल बनाने के लिए, हमने एक आर्किटेक्ट उदाहरण बनाने के लिए एक सरल तरीका सोचा: पहले आप एक JsonSchemaRegistry (स्कीमा का परीक्षण करने के लिए) बनाएं , फिर टेस्टिंगअर्किटेक्टहोस्ट और अंत में, एक आर्किटेक्ट उदाहरण। अब आप builders.json कॉन्फ़िगरेशन फ़ाइल संकलित कर सकते हैं।

यहां कलेक्टर को चलाने का एक उदाहरण है, जो ls कमांड को निष्पादित करता है और सत्यापित करता है कि कमांड सफलतापूर्वक पूरा हुआ। कृपया ध्यान दें कि हम लकड़हारे में प्रक्रियाओं के मानक उत्पादन का उपयोग करेंगे।

 import { Architect, ArchitectHost } from '@angular-devkit/architect'; import { TestingArchitectHost } from '@angular-devkit/architect/testing'; import { logging, schema } from '@angular-devkit/core'; describe('Command Runner Builder', () => { let architect: Architect; let architectHost: ArchitectHost; beforeEach(async () => { const registry = new schema.CoreSchemaRegistry(); registry.addPostTransform(schema.transforms.addUndefinedDefaults); //  TestingArchitectHost –    . //     ,   . architectHost = new TestingArchitectHost(__dirname, __dirname); architect = new Architect(architectHost, registry); //      NPM-, //    package.json  . await architectHost.addBuilderFromPackage('..'); }); //      Windows it('can run ls', async () => { //  ,     . const logger = new logging.Logger(''); const logs = []; logger.subscribe(ev => logs.push(ev.message)); // "run"    ,       . const run = await architect.scheduleBuilder('@example/command-runner:command', { command: 'ls', args: [__dirname], }, { logger }); // "result" –    . //    "BuilderOutput". const output = await run.result; //  . Architect     //   ,    ,    . await run.stop(); //   . expect(output.success).toBe(true); // ,     . // `ls $__dirname`. expect(logs).toContain('index_spec.ts'); }); }); 

ऊपर दिए गए उदाहरण को चलाने के लिए, आपको ts-node पैकेज की आवश्यकता है। यदि आप नोड का उपयोग करने का इरादा रखते हैं, तो index_spec.ts को index_spec.js का नाम बदलें।

एक परियोजना में कलेक्टर का उपयोग करना

आइए एक सरल कोणीय बनाते हैं। Json जो सब कुछ दिखाता है जो हमने कोडांतरकों के बारे में सीखा है। यह मानकर कि हमने अपने कलेक्टर को उदाहरण / कमांड-रनर में पैक किया है और फिर नए बिल्डर-टेस्ट का उपयोग करके एक नया एप्लिकेशन बनाया है, कोणीय . json फ़ाइल इस तरह दिख सकती है (कुछ सामग्री संक्षिप्तता के लिए हटा दी गई है):

 { // ...   . "projects": { // ... "builder-test": { // ... "architect": { // ... "build": { "builder": "@angular-devkit/build-angular:browser", "options": { // ...   "outputPath": "dist/builder-test", "index": "src/index.html", "main": "src/main.ts", "polyfills": "src/polyfills.ts", "tsConfig": "src/tsconfig.app.json" }, "configurations": { "production": { // ...   "optimization": true, "aot": true, "buildOptimizer": true } } } } 

अगर हमने अपने कलेक्टर का उपयोग करके फ़ाइल के लिए टच कमांड (उदाहरण के लिए फ़ाइल संशोधन तिथि) को लागू करने के लिए एक नया कार्य जोड़ने का फैसला किया है, तो हम npm स्थापित उदाहरण / कमांड-रनर चलाएंगे , और फिर angular.json में परिवर्तन करेंगे :

 { "projects": { "builder-test": { "architect": { "touch": { "builder": "@example/command-runner:command", "options": { "command": "touch", "args": [ "src/main.ts" ] } }, "build": { "builder": "@angular-devkit/build-angular:browser", "options": { "outputPath": "dist/builder-test", "index": "src/index.html", "main": "src/main.ts", "polyfills": "src/polyfills.ts", "tsConfig": "src/tsconfig.app.json" }, "configurations": { "production": { "fileReplacements": [ { "replace": "src/environments/environment.ts", "with": "src/environments/environment.prod.ts" } ], "optimization": true, "aot": true, "buildOptimizer": true } } } } } } } 

कोणीय सीएलआई में एक रन कमांड है, जो कलेक्टरों को चलाने के लिए मुख्य कमांड है। पहले तर्क के रूप में, यह PROJECT: TASK [: CONFIGURATION] प्रारूप की एक स्ट्रिंग लेता है। अपने कार्य को चलाने के लिए, हम एनजी रन बिल्डर-टेस्ट: टच कमांड का उपयोग कर सकते हैं।

अब हम कुछ तर्कों को फिर से परिभाषित करना चाहते हैं। दुर्भाग्य से, हम अब तक कमांड लाइन से सरणियों को फिर से परिभाषित नहीं कर सकते हैं, हालांकि हम कमांड को स्वयं प्रदर्शन के लिए बदल सकते हैं: एनजी रन बिल्डर-टेस्ट: स्पर्श - युआन = एलएस । - यह src / main.ts फाइल को आउटपुट करेगा।

देखो मोड

डिफ़ॉल्ट रूप से, यह माना जाता है कि कलेक्टरों को एक बार बुलाया जाएगा और समाप्त कर दिया जाएगा, हालांकि, वे ऑब्जर्वेबल को अपने स्वयं के अवलोकन मोड (जैसा कि वेबपैक कलेक्टर करता है) को लागू करने के लिए वापस कर सकते हैं। आर्किटेक्ट तब तक ऑब्जर्वेबल की सदस्यता लेगा, जब तक वह खत्म या बंद नहीं हो जाता है और कलेक्टर को फिर से सदस्यता दे सकता है यदि कलेक्टर को उसी मापदंडों के साथ कहा जाता है (यद्यपि गारंटी नहीं है)।

1. कलेक्टर को प्रत्येक निष्पादन के बाद एक बिल्डरऑउटपुट ऑब्जेक्ट वापस करना चाहिए। पूरा होने के बाद, यह एक बाहरी घटना के कारण अवलोकन मोड में प्रवेश कर सकता है और, अगर यह फिर से शुरू होता है, तो इसे आर्किटेक्ट को सूचित करने के लिए reference.reportRunning () फ़ंक्शन को कॉल करना होगा कि कलेक्टर फिर से काम कर रहा है। यह कलेक्टर को नए कॉल पर आर्किटेक्ट द्वारा इसे रोकने से बचाएगा।
2. आर्किटेक्ट खुद को ऑब्जर्वेबल से अनसब्सक्राइब करता है जब कलेक्टर बंद हो जाता है (रन.स्टॉप (), उदाहरण के लिए), टियरडाउन तर्क का उपयोग करके - विनाश एल्गोरिथ्म। यह आपको असेंबली को रोकने और साफ़ करने की अनुमति देगा यदि यह प्रक्रिया पहले से ही चल रही है।

उपरोक्त सारांश, यदि आपका कलेक्टर बाहरी घटनाओं को देखता है, तो यह तीन चरणों में काम करता है:

1. निष्पादन। उदाहरण के लिए, वेबपैक का संकलन। यह कदम तब समाप्त होता है जब वेबपैक भवन का निर्माण पूरा करता है और आपका कलेक्टर बिल्डरवर्टपुट को अवलोकन के लिए भेजता है।
2. अवलोकन। - दो लॉन्च के बीच, बाहरी घटनाओं की निगरानी की जाती है। उदाहरण के लिए, वेबपैक किसी भी बदलाव के लिए फाइल सिस्टम की निगरानी करता है। यह कदम तब समाप्त होता है जब वेबपैक बिल्ड और संदर्भ को फिर से शुरू करता है ।reportRunning () कहा जाता है। इस चरण के बाद, चरण 1 फिर से शुरू होता है।
3. समापन। - कार्य पूरी तरह से पूरा हो गया है (उदाहरण के लिए, यह उम्मीद की गई थी कि वेबपैक एक निश्चित संख्या में शुरू होगा) या कलेक्टर की शुरुआत बंद हो गई थी ( रन.स्टॉप () का उपयोग करके)। इस मामले में, ऑब्जर्वेबल विनाश एल्गोरिथ्म को निष्पादित किया जाता है, और यह साफ हो जाता है।

निष्कर्ष

इस प्रकाशन में हमने जो कुछ सीखा, उसका सारांश इस प्रकार है:

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

निकट भविष्य में, इन एपीआई के उपयोग की आवृत्ति बढ़ जाएगी। उदाहरण के लिए, बज़ेल कार्यान्वयन उनके साथ दृढ़ता से जुड़ा हुआ है।

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