كيفية تقليل وقت تثبيت الحزم من 28 دقيقة إلى 47 ثانية باستخدام Bun
makedream٨ مايو ٢٠٢٦
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 agents). بعيداً عن السبب الظاهري المتمثل في السرعة، سنتحدث عن طرق الهجرة العملية وتصميم الهيكلية في العمل الفعلي.
تمت إعادة كتابة Bun من الصفر باستخدام لغة Zig. وبفضل ذلك، أصبح تثبيت الحزم أسرع بمراحل من Node.js v22. ومع ذلك، إذا حاولت استخدام Bun مع الإبقاء على ملف package-lock.json الحالي، فستتعقد ملفات القفل وستتعالى الصرخات من أجهزة النشر. في هذه الحالة، لا تحاول الجمع بينهما بشكل ناقص، بل أعد بناء الأساس من جديد.
أولاً، احذف مجلد node_modules وملف القفل الحالي بجرأة. بعد ذلك، قم بتشغيل bun install --frozen-lockfile في التيرمينال، وسيتم إنشاء ملف القفل الثنائي الخاص بـ Bun وهو bun.lockb. بالنسبة للمكتبات التي تستخدم إضافات C++ وتسبب أخطاء في التجميع مثل bcrypt، فمن الأفضل لصحتك النفسية استبدالها بـ bcryptjs أو استخدام واجهات برمجة التطبيقات المدمجة في Bun مثل bun:sqlite. إن تجربة تقليص وقت العمل من 28 دقيقة إلى 47 ثانية في مشروع يحتوي على أكثر من 1,800 تبعية هي تجربة مثيرة حقاً.
عندما تعطي وكلاء الذكاء الاصطناعي المعتمدين على نماذج اللغة الكبيرة (LLM) ملفات تحتوي على آلاف الأسطر، فإنهم سرعان ما يفقدون طريقهم ويبدأون بالهذيان. وبما أن Bun سريع جداً في عمليات الإدخال والإخراج للملفات (I/O)، فإن تقسيم الملفات إلى أجزاء صغيرة جداً لا يؤثر تقريباً على الأداء. ولزيادة الدقة عندما يقوم الوكيل بتعديل الكود، يفضل استخدام هيكلية تحافظ على كل ملف ضمن حدود 100 سطر.
أنا أقوم بإنشاء مجلدات مفصلة تماماً حسب الوظيفة مثل src/agents و src/tools داخل المشروع. ثم أربط Bun.serve مع Bun.file لبناء بوابة تسمح بالتعامل مع مجلدات محددة فقط. التحقق من المسار باستخدام targetPath.startsWith يمنع وقوع حوادث مثل قيام الوكيل بالنبش في إعدادات نظام الماك بوك الخاص بي. إنها هيكلية تضمن الأمان وتوفر في تكاليف التوكنات (Tokens).
إذا استدعى وكيل الذكاء الاصطناعي أداة ما وتأخر الرد لفترة طويلة، فستتضرر تجربة المستخدم. يعتمد Express أسلوب البحث المتسلسل عند العثور على المسارات، مما يجعله بطيئاً مع زيادة الطلبات. في المقابل، يستخدم Hono خوارزمية Trie للعثور على المسار فوراً.
في الواقع، عند دمج Bun مع Hono، يرتفع معدل معالجة الطلبات في الثانية (RPS) إلى حوالي 41,800 طلب. هذا أسرع بأكثر من 3 مرات من Express. ابدأ بـ bun add hono واقرأ متغيرات البيئة مباشرة عبر Bun.env. وإذا أضفت إلى ذلك واجهة برمجة تطبيقات WebSocket عالية الأداء من Bun، يمكنك حصر زمن تأخير الاستجابة في حدود 27ms. لن تضطر لمشاهدة الذكاء الاصطناعي وهو ينتظر ببلادة بسبب خادم بطيء.
استخدامك لـ Bun بمفردك لن يحل المشكلة. يجب على جميع أعضاء الفريق استخدام نفس البيئة لتجنب الحوادث في مرحلة الإنتاج. ضع ملف .bunfig.toml في المجلد الرئيسي (Root) وثبّت فيه معلومات السجل الخاص (Private Registry) أو خيارات ملف القفل. هذا يقلل من الوقت الذي قد يضيعه الأعضاء الجدد في المحاولة والخطأ.
عند النشر، يجب الانتباه إلى حجم صورة Docker. استخدم صورة oven/bun:1 كقاعدة، واستغل خيار bun build --compile لتحويل الكود المصدري إلى ملف تنفيذي واحد. إذا استخرجت هذا الملف فقط ووضعته في صورة distroless كقاعدة، فسينخفض حجم صورة Node.js التي كانت تتجاوز 1 جيجابايت إلى أقل من 200 ميجابايت. عندما يصغر حجم الصورة، تنخفض تكاليف البنية التحتية السحابية بنحو 40%، فلا يوجد سبب لعدم القيام بذلك.