Bun के साथ पैकेज इंस्टालेशन समय को 28 मिनट से घटाकर 47 सेकंड कैसे करें
makedream8 mai 2026
0
Computing/Software
Comments (0)
Log in to leave a comment
No posts yet
makedreammakedreamLog in to leave a comment
No posts yet
Node.js परिवेश में डिपेंडेंसी के ढेर से जूझते समय, अक्सर यह भ्रम हो जाता है कि मैं कोड लिख रहा हूँ या सिर्फ इंस्टालेशन बार को देख रहा हूँ। Bun केवल एक तेज़ रनटाइम होने से कहीं आगे जाकर AI एजेंटों के साथ सहयोग करने के लिए एक बेहतरीन मंच तैयार करता है। गति के सतही कारण के पीछे छिपे व्यावहारिक माइग्रेशन (migration) के तरीकों और संरचना डिजाइन की कहानी के बारे में बात करते हैं।
Bun को Zig भाषा का उपयोग करके बिल्कुल शुरुआत से बनाया गया है। इसके कारण, यह Node.js v22 की तुलना में पैकेज इंस्टालेशन में बहुत तेज़ है। हालाँकि, यदि आप मौजूदा package-lock.json को बनाए रखते हुए Bun का उपयोग करते हैं, तो लॉकफ़ाइल उलझ सकती है, जिससे डिप्लॉयमेंट मशीनों पर समस्याएँ आ सकती हैं। ऐसे में, आधे-अधूरे प्रयासों के बजाय सब कुछ नए सिरे से सेट करना बेहतर है।
सबसे पहले, node_modules और मौजूदा लॉकफ़ाइल को बेझिझक हटा दें। उसके बाद, टर्मिनल में bun install --frozen-lockfile चलाएँ, जिससे Bun की अपनी बाइनरी लॉकफ़ाइल bun.lockb बन जाएगी। bcrypt जैसे पुस्तकालयों के लिए जो C++ एड-ऑन का उपयोग करते हैं और कंपाइल एरर देते हैं, उन्हें bcryptjs से बदलना या Bun के बिल्ट-इन API bun:sqlite का उपयोग करना मानसिक शांति के लिए बेहतर है। 1,800 से अधिक डिपेंडेंसी वाले प्रोजेक्ट में 28 मिनट लगने वाले काम को 47 सेकंड में पूरा होते देखना काफी रोमांचक अनुभव है।
यदि आप LLM-आधारित AI एजेंट को हज़ारों लाइनों वाली फ़ाइल देते हैं, तो वह जल्दी ही रास्ता भटक जाता है और गलतियाँ करने लगता है। चूंकि Bun का फ़ाइल I/O बहुत तेज़ है, इसलिए फ़ाइलों को छोटे टुकड़ों में बाँटने पर भी प्रदर्शन में लगभग कोई कमी नहीं आती है। एजेंट द्वारा कोड संशोधित करते समय सटीकता बढ़ाने के लिए, प्रति फ़ाइल 100 लाइनों के भीतर रखने वाली संरचना फायदेमंद होती है।
मैं प्रोजेक्ट के भीतर src/agents और src/tools जैसे पूरी तरह से अलग कार्यों वाले फ़ोल्डर बनाता हूँ। फिर, Bun.serve और Bun.file को जोड़कर एक ऐसा गेटवे बनाता हूँ जो केवल विशिष्ट निर्देशिकाओं (directories) तक ही पहुँच दे सके। targetPath.startsWith के साथ पथ (path) को सत्यापित करने से AI एजेंट को मेरे मैकबुक की सिस्टम सेटिंग्स में ताकाझांकी करने से रोका जा सकता है। यह सुरक्षा और टोकन लागत दोनों की बचत करने वाली संरचना है।
जब एक AI एजेंट किसी टूल को कॉल करता है और प्रतिक्रिया बहुत देर बाद आती है, तो उपयोगकर्ता का अनुभव खराब हो जाता है। Express रूट ढूंढते समय क्रमिक (sequential) तरीके का उपयोग करता है, इसलिए अनुरोध बढ़ने पर यह धीमा हो जाता है। इसके विपरीत, Hono 'ट्राई (Trie)' एल्गोरिथ्म का उपयोग करता है, जिससे वह तुरंत पथ ढूंढ लेता है।
वास्तव में, Bun और Hono को मिलाने पर प्रति सेकंड अनुरोध प्रसंस्करण (RPS) लगभग 41,800 तक पहुँच जाता है। यह Express से 3 गुना अधिक तेज़ है। bun add hono के साथ शुरुआत करें और एनवायरनमेंट वेरिएबल्स को सीधे Bun.env से पढ़ें। इसमें Bun के हाई-परफॉर्मेंस WebSocket API को जोड़कर, आप रियल-टाइम रिस्पॉन्स लेटेंसी को 27ms के स्तर तक सीमित रख सकते हैं। अब आपको सुस्त सर्वर के कारण AI के खाली बैठने का इंतज़ार नहीं करना पड़ेगा।
केवल मेरे द्वारा Bun का उपयोग करने से समस्या हल नहीं होगी। प्रोडक्शन में दुर्घटनाओं से बचने के लिए टीम के सभी सदस्यों को एक ही परिवेश का उपयोग करना चाहिए। रूट में .bunfig.toml फ़ाइल रखें और उसमें प्राइवेट रजिस्ट्री जानकारी या लॉकफ़ाइल विकल्पों को फिक्स करें। यह नए टीम सदस्यों के आने पर उनके समय की बर्बादी को कम करता है।
डिप्लॉयमेंट के समय Docker इमेज के साइज़ पर ध्यान देना ज़रूरी है। oven/bun:1 इमेज को बेस के रूप में उपयोग करें और सोर्स कोड को सिंगल एक्जीक्यूटेबल फ़ाइल बनाने के लिए bun build --compile विकल्प का उपयोग करें। यदि आप केवल इस फ़ाइल को चुनकर distroless इमेज में डालते हैं, तो 1GB से अधिक की Node.js इमेज घटकर 200MB से कम हो जाती है। जब इमेज का साइज़ छोटा होता है, तो क्लाउड इंफ्रास्ट्रक्चर लागत लगभग 40% तक कम हो जाती है, इसलिए इसे न करने का कोई कारण नहीं है।