प्लग इन जोड़ना

इस दस्तावेज़ में, नया प्लगिन बनाने का तरीका बताया गया है. इसमें पहले पक्ष के प्लगिन बनाने की प्रोसेस के बारे में बताया गया है. हालांकि, इसका इस्तेमाल तीसरे पक्ष के प्लगिन बनाने के लिए दिशा-निर्देश के तौर पर किया जा सकता है.

प्लगिन के बारे में खास जानकारी के लिए, प्लगिन देखें.

प्लगिन बनाने के बारे में तुरंत जानकारी पाने के लिए, प्लगिन बनाने का तरीका टॉक (2021) देखें.

पहले पक्ष की ऑडियंस बनाम तीसरे पक्ष की ऑडियंस

किसी प्लगिन का टारगेट उपयोगकर्ता, एक डेवलपर होता है. यह डेवलपर, npm के ज़रिए प्लगिन ढूंढता है और उसका इस्तेमाल करता है.

पहले पक्ष के प्लगिन, Blockly टीम के साथ काम करते हैं. इन्हें npm पर @blockly स्कोप में पब्लिश किया जाता है. इन्हें Blockly के कई ऐप्लिकेशन में इस्तेमाल किया जा सकता है. साथ ही, ये स्थिर और इस्तेमाल में आसान होते हैं. ये blockly-samples में सेव होते हैं. मोटर की स्पीड सेट करने के लिए फ़ील्ड का इस्तेमाल कई रोबोटिक्स प्रोजेक्ट में किया जा सकता है. साथ ही, यह पहले-पक्ष के प्लगिन के लिए एक अच्छा विकल्प है.

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

पहले पक्ष की ज़रूरी शर्तें

पहले पक्ष के प्लगिन को ये ज़रूरी शर्तें पूरी करनी होंगी:

  • सभी मुख्य प्लैटफ़ॉर्म पर काम करना चाहिए. हालांकि, Blockly टीम से छूट मिलने पर ऐसा नहीं करना होगा.
    • Chrome, Firefox, Safari, Edge
  • आपके पास एक ऐसा लेखक होना चाहिए जो पहले साल में बग ठीक करने के लिए तैयार हो.
  • Blockly में मंकीपैचिंग न करें.
  • एपीआई के बारे में साफ़ तौर पर जानकारी दी गई हो और उसके बारे में दस्तावेज़ मौजूद हो.
  • Blockly कोर से निजी या पैकेज फ़ंक्शन को कॉल न करें. ऐसा तब तक न करें, जब तक Blockly टीम से आपको छूट न मिली हो.
    • आपके पास, अपनी तय की गई सबक्लास पर पैकेज फ़ंक्शन को बदलने की अनुमति होती है.
    • अगर आपको छूट चाहिए, तो blockly-samples पर किसी समस्या के बारे में हमें बताएं.
  • जांच की सुविधा हो.

प्रक्रिया

प्लगिन चार चरणों से गुज़रते हैं: सुझाव, चर्चा, लागू करना, और पब्लिश करना.

सुझाव

कोई प्लगिन, सुझाव के तौर पर दिखता है. सुविधा का अनुरोध टेंप्लेट का इस्तेमाल करके, नई समस्या बनाकर किसी प्लगिन का सुझाव दिया जा सकता है. ज़्यादा जानकारी के लिए, सुविधा के लिए अनुरोध करने का तरीका लेख पढ़ें.

सुविधा के अनुरोध के बारे में बुनियादी जानकारी के अलावा, प्लगिन के सुझाव में यह जानकारी भी शामिल होनी चाहिए:

  • यह प्लगिन, एपीआई को ऐक्सेस करने की अनुमति देगा.
  • प्लगिन के साथ काम करने के लिए, Blockly के मुख्य कोड में जोड़े जाने या बदले जाने वाले एपीआई.
  • अगर प्लगिन में यूज़र इंटरफ़ेस (यूआई) से जुड़ी सुविधाएं शामिल हैं, तो उनके स्क्रीनशॉट, GIF या मॉक-अप.
  • इस बारे में जानकारी कि इसे तीसरे पक्ष के प्लगिन के बजाय, पहले पक्ष का प्लगिन क्यों होना चाहिए.

Blockly टीम, सुझावों की समीक्षा करती है. इसके बाद, वह या तो समस्या को बंद कर देती है या इस बात से सहमत होती है कि यह पहले पक्ष का अच्छा प्लगिन होगा.

बातचीत

इसके बाद, प्लगिन discussion फ़ेज़ में जाता है. इस फ़ेज़ में ये चीज़ें शामिल हैं:

  • ज़रूरत के मुताबिक फ़ंक्शन के बारे में जानकारी.
  • प्लगिन के एपीआई के बारे में ज़्यादा जानकारी.
  • लागू करने की योजना बनाना.
  • टेस्ट के लिए प्लान बनाना.
  • कोर Blockly में एपीआई से जुड़े बदलावों के बारे में चर्चा.
  • बड़े प्लगिन को लागू करने के चरणों में बांटना.
  • हमारे नाम रखने के तरीकों के आधार पर, प्लगिन का नाम रखना.
  • पुष्टि करना कि पहले पक्ष की सभी शर्तें पूरी की गई हैं.

आम तौर पर, यह चर्चा GitHub की समस्या पर होती है. प्लगिन का दायरा जितना छोटा होगा, चर्चा उतनी ही तेज़ी से हो पाएगी. बड़े प्लगिन, कम्यूनिटी का ध्यान खींच सकते हैं. साथ ही, सही समाधान के बारे में लोगों की राय भी मिल सकती है. अगर आपकी समस्या के साथ ऐसा होता है, तो बधाई! आपको ऐसी चीज़ मिली है जिसमें लोगों की दिलचस्पी है.

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

बातचीत के दौरान, हम यह तय कर सकते हैं कि कोई प्लगिन तीसरे पक्ष का प्लगिन होना चाहिए. साथ ही, उसे @blockly स्कोप के तहत पब्लिश नहीं किया जाना चाहिए. ऐसे में, हम आपको इसकी वजह बताएंगे और समस्या को हल कर देंगे.

चर्चा पूरी होने के बाद, Blockly टीम का कोई सदस्य यह सूचना देता है कि इसे लागू किया जा सकता है.

लागू करना

लागू करने के चरणों में ये शामिल हैं:

  • टेंप्लेट से प्लग इन और उसकी डायरेक्ट्री सेट अप करने के लिए, npx @blockly/create-package को चलाया जा रहा है. ज़्यादा जानें...
  • प्लगिन के लिए मुख्य लॉजिक लागू करना.
  • ज़रूरत पड़ने पर यूज़र इंटरफ़ेस (यूआई) लागू करना.
  • Mocha का इस्तेमाल करके प्लगिन की जांच करना.
  • प्लगिन के बारे में जानकारी देने वाला दस्तावेज़, जिसमें README शामिल हो.

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

इसे एक साथ कई लोग लागू कर सकते हैं. आपके पास अपने फ़ोर्क पर, साथ मिलकर प्लग-इन लागू करने का विकल्प होता है. इसके अलावा, इस रिपॉज़िटरी के लिए पुल अनुरोधों के ज़रिए भी ऐसा किया जा सकता है. अगर आपको इस रिपॉज़िटरी में किसी प्लगिन पर साथ मिलकर काम करना है, तो Blockly टीम से अपने लिए एक फ़ीचर ब्रांच बनाने के लिए कहें.

प्लगिन को blockly-samples की master ब्रांच में मौजूद gh-pages/index.md फ़ाइल में जोड़ा जाना चाहिए. इससे वे हमारी Plugins site पर दिखेंगे. पहले पक्ष के प्लगिन को अपने टेस्ट पेज पर रीडायरेक्ट करना चाहिए. इस पेज पर तीसरे पक्ष के प्लगिन भी जोड़े जा सकते हैं. साथ ही, इन्हें इनके मालिक की पसंद के लिंक पर रीडायरेक्ट किया जा सकता है. जैसे, होस्ट किया गया डेमो या npm पेज.

पब्लिशिंग

आखिर में, पब्लिश करना. Blockly टीम, सभी प्लगिन के वर्शन और उन्हें पब्लिश करने के लिए Lerna का इस्तेमाल करती है.

हर गुरुवार को, ऐसे सभी प्लगिन पब्लिश किए जाते हैं जिनमें पिछली रिलीज़ के बाद बदलाव हुए हैं. अगर आपको बदलाव को जल्द पब्लिश करना है, तो कृपया पुल अनुरोध में इसकी जानकारी दें.

जब भी प्लग इन पब्लिश किए जाते हैं, तब प्लग इन की साइट भी अपडेट हो जाती है.

जिन प्लगिन को पब्लिश नहीं किया जाना है उन्हें private के तौर पर मार्क किया जाना चाहिए.package.json ऐसा तब हो सकता है, जब कोई प्लगिन Core Blockly में किए गए ऐसे बदलाव पर निर्भर करता हो जिसे अब तक पब्लिश नहीं किया गया है. Core Blockly को हर तिमाही के आखिरी हफ़्ते में पब्लिश किया जाता है. यानी, हर तीन महीने में एक बार.