स्ट्रीम-ऑफ-कॉन्शसनेस में विकसित JavaScript bundler (Zig Native typescript Transpiler & Compiler)
(github.com/ohah)AI के युग में पढ़ाई कैसे करनी चाहिए?
किस तरह की विशेषज्ञता की ज़रूरत है, और इस समय किस क्षमता की सबसे अधिक कीमत है, इसका मुझे अंदाज़ा नहीं था।
डेवलपरों को hiring करने वाली कंपनियाँ भी, और डेवलपर भी, शायद स्पष्ट मानदंड नहीं जानते होंगे।
फिर भी, मुझे लगा कि अगर चुपचाप बैठे रहे तो निश्चित रूप से नुकसान होगा।
तो सोचा, पहले कुछ न कुछ बनाकर देखते हैं।
सीखने के लिए शुरुआत में मैंने बस एक साधारण Chrome remote devtool बनाने से शुरुआत की।
बनाते-बनाते लगा, React Native को भी remote debugger के रूप में support होने लायक बना कर देखें।
-> Metro को न जानने की वजह से बहुत भ्रम हो रहा है।
-> Metro का clone coding करते हुए सीखते हैं।
-> क्या React Native में Metro से बेहतर bundler नहीं बनाया जा सकता?
-> rolldown, swc, bun के साथ यह-वह आज़माते हुए Metro bundler से बेहतर bundler बनाने की कोशिश।
उनमें से bun और rolldown में कुछ संभावना दिखी, लेकिन main side पर तरह-तरह की customization या fork निकालने में सीमाएँ महसूस हुईं।
ऊपर से Metro bundler के साथ पूरी तरह compatible कोई web bundler भी नहीं है — flow, Hermes engine द्वारा स्वीकार किया जाने वाला JavaScript syntax, और सामान्य web से अलग महत्वपूर्ण call order जैसी चीज़ें भी हैं।
आह... खैर, वैसे भी यह सब सीखने के लिए ही कर रहा हूँ, तो bundler भी खुद ही बनाकर React Native Metro को replace करके देखते हैं।
bundler बनाते समय जो महसूस हुआ:
तो फिर web को भी support कर दें, है ना?
rolldown में छोड़े गए ES5 को भी डालें।
RN चलाना है, तो Flow parser को भी support करें।
wasm भी support करें।
speed में भी bun, rolldown को हराने की कोशिश करें।
अपना खुद का HMR भी डालें।
Tree-shaking को थोड़ा और aggressive बनाएं।
minify भी दूसरे bundlers की तुलना में आगे ले जाएँ।
मैंने यह सोचकर development किया कि benchmark में मौजूद bundlers के सामने, कम से कम जिन features को मैं पहचानता हूँ, उनमें सबको पछाड़ना है।
बेशक, मुझे लगता है कि कई जगहों पर मैं अभी भी पीछे हूँ।
दूसरे bundlers की तुलना में stability, features, supported ecosystem community आदि में, और ऊपर बताए गए tree-shaking या minify जैसे हिस्सों में भी कुछ modules पर बेहतर लेकिन कुछ modules पर कमजोर — यानी स्वाभाविक रूप से अभी बहुत कुछ अधूरा है।
फिर भी, कुछ execution tests के नतीजों में कुछ हिस्सों में बढ़त दिखी है, और अभी भी करने के लिए बहुत कुछ बाकी है (SSL, MCP, CLI, stabilization, API docs आदि)। लेकिन मूल लक्ष्य, यानी React Native app build और execution, के लिए 3 commercial apps पर release build, development build, और development server की जाँच की गई, और सब बिना समस्या के चलता हुआ मिला। इसलिए लगा कि अब इसे public कर दिया जाए और आगे लगातार development किया जाए — इसी सोच से यह पोस्ट लिखी।
फिर भी development और bundle features (zntc भी zntc से build करके distribute किया जाता है) काफ़ी हद तक अच्छी तरह काम कर रहे हैं,
और essential feature decorators, React Native में semi-essential worklet, typescript, flow आदि के साथ जिन libraries को test किया गया, वे बिना समस्या के ठीक चलीं।
साथ ही vite और rspack के लिए plugins भी दिए गए हैं, vite और rspack की तरह development environment भी दिया गया है (RN, Web), docs भी हैं, React HMR भी है, module federation भी support करता है, वगैरह-वगैरह।
तो मुझे लगा कि कम से कम bundler और transpiler की बुनियादी क्षमताएँ इसमें आ गई हैं, इसलिए feedback लेने के लिए इसे public करके आगे development जारी रखना चाहता हूँ।
हाथ से लिखा गया code शून्य है; सब कुछ AI के साथ तीखी बहस करते हुए विकसित किया गया है।
लगता है, किसी भी दूसरे product development से ज़्यादा AI को इसी में खपाया।
पहले सिर्फ Claude इस्तेमाल कर रहा था, बाद में Codex भी इस्तेमाल किया।
bundler के अपने development की अवधि लगभग 3 महीने रही (लगभग 3000 PR), और ऊपर बताई गई इस पूरी stream-of-consciousness यात्रा को शामिल करें तो लगभग 6 महीने तक दिन-रात लगातार काम किया।
सप्ताह के दिन हों या छुट्टी, बिना रुके काम किया।
और दूसरे bundlers से बेवजह की तुलना से आने वाली हीनभावना? या कहें एक तरह की मानसिकता के कारण,
test262 100% जैसे विभिन्न test cases पास कराने के लिए test cases भी हद से ज़्यादा लिखकर development किया।
कृपया बहुत सारा feedback दें (__)
5 टिप्पणियां
Metro के विकल्प के रूप में, RSPack या WebPack का उपयोग करने वाला Re.Pack भी है.
बिखरे ढंग से लिखते-लिखते यह बात छूट गई थी.
जैसा आपने कहा, मैंने Re.pack को भी काफी रेफ़र किया है.
मेरी जानकारी के अनुसार Re.pack और Rspack दोनों swc-आधारित हैं, इसलिए वे flow को native रूप में सपोर्ट नहीं करते.
Re.pack के मामले में, मेरी जानकारी के अनुसार version 5 से यह Rspack-आधारित है, और इसी तरह Re.pack भी swc+babel का उपयोग करता है, इसलिए flow, reanimated, nativewind (zntc में सपोर्ट की योजना है) जैसे लोकप्रिय plugins अब भी Babel से transpile होते हैं.
व्यक्तिगत तौर पर मैं Babel से बाहर निकलना चाहता था, इसलिए zntc के मामले में मैंने इसे ऐसा विकल्प बनाया जो डिफ़ॉल्ट रूप से सपोर्ट होता है.
zntc भी Babel compatibility सपोर्ट करता है, लेकिन मैं यथासंभव Babel dependency को शून्य करना चाहता था.
यह कोड काफ़ी stable हैं और अच्छी तरह परखे हुए भी हैं, लेकिन JS की सीमाओं की वजह से speed में हमेशा bottleneck रहता है.
असल में, development के दौरान मैं लगातार दूसरे bundlers के साथ benchmark तुलना करता रहा, और जैसा मैंने ख़ुद बार-बार महसूस किया, स्वाभाविक है कि दूसरे bundlers की तुलना में features, stability और scalability में अभी कमी है, इसलिए मैं इस हिस्से को लगातार बेहतर बनाने की कोशिश कर रहा हूँ.
हालाँकि, क्योंकि प्रमुख React Native libraries की parser compatibility आदि इसमें पूरी तरह built-in है, इसलिए मुझे लगता है कि Re.pack में जो structural bottleneck वाले हिस्से अनिवार्य रूप से पैदा होते हैं, उनके मामले में यह आगे है!
यह आसान प्रोजेक्ट नहीं होगा, फिर भी मेरा समर्थन है।
धन्यवाद!!
उम्... test262 100% है... सिर्फ बैज देखकर मुझे लगा था कि यह V8-लेवल का होगा, हाहा