Skip to content

إذا لم يتم العثور على دليل node_modules في دليل العمل أو أعلى، سيتخلى Bun عن قرار الوحدات النمطية بأسلوب Node.js لصالح خوارزمية قرار الوحدات النمطية لـ Bun.

تحت قرار الوحدات النمطية بأسلوب Bun، يتم تثبيت جميع الحزم المستوردة تلقائياً على الطاير في وحدة تخزين مؤقتة عالمية أثناء التنفيذ (نفس وحدة التخزين المؤقتة المستخدمة بواسطة bun install).

ts
import { foo } from "foo"; // تثبيت إصدار `latest`

foo();

في المرة الأولى التي تشغل فيها هذا السكربت، سيقوم Bun بتثبيت "foo" تلقائياً وتخزينه في وحدة التخزين المؤقتة. في المرة التالية التي تشغل فيها السكربت، سيستخدم الإصدار المخزن مؤقتاً.


قرار الإصدار

لتحديد الإصدار الذي يجب تثبيته، يتبع Bun الخوارزمية التالية:

  1. التحقق من وجود ملف bun.lock في جذر المشروع. إذا كان موجوداً، استخدم الإصدار المحدد في ملف القفل.
  2. بخلاف ذلك، امسح الشجرة لأعلى للبحث عن package.json يتضمن "foo" كاعتمادية. إذا تم العثور عليه، استخدم إصدار semver المحدد أو نطاق الإصدار.
  3. بخلاف ذلك، استخدم latest.

سلوك وحدة التخزين المؤقتة

بمجرد تحديد الإصدار أو نطاق الإصدار، سيقوم Bun بـ:

  1. التحقق من وحدة التخزين المؤقتة للوحدة النمطية للحصول على إصدار متوافق. إذا كان موجوداً، استخدمه.
  2. عند حل latest، سيتحقق Bun مما إذا كان package@latest قد تم تنزيله وتخزينه مؤقتاً في آخر 24 ساعة. إذا كان كذلك، استخدمه.
  3. بخلاف ذلك، قم بتنزيل وتثبيت الإصدار المناسب من سجل npm.

التثبيت

يتم تثبيت الحزم وتخزينها مؤقتاً في <cache>/<pkg>@<version>، لذا يمكن تخزين إصدارات متعددة من نفس الحزمة في وقت واحد. بالإضافة إلى ذلك، يتم إنشاء symlink تحت <cache>/<pkg>/<version> لجعل البحث عن جميع إصدارات الحزمة الموجودة في وحدة التخزين المؤقتة أسرع.


محددات الإصدار

يمكن اختصار خوارزمية القرار بأكملها عن طريق تحديد إصدار أو نطاق إصدار مباشرة في بيان الاستيراد الخاص بك.

ts
import { z } from "zod@3.0.0"; // إصدار محدد
import { z } from "zod@next"; // علامة npm
import { z } from "zod@^3.20.0"; // نطاق semver

الفوائد

نهج التثبيت التلقائي هذا مفيد لعدة أسباب:

  • كفاءة المساحة — كل إصدار من الاعتماديات يوجد في مكان واحد فقط على القرص. هذا يوفر مساحة ووقتاً هائلاً مقارنة بالتثبيتات الزائدة لكل مشروع.
  • إمكانية النقل — لمشاركة السكربتات البسيطة و gists، ملف المصدر الخاص بك مكتفٍ ذاتياً. لا حاجة لـ zip معاً دليل يحتوي على ملفات الكود والتكوين الخاصة بك. مع محددات الإصدار في بيانات import، حتى package.json ليس ضرورياً.
  • الراحة — لا حاجة لتشغيل npm install أو bun install قبل تشغيل ملف أو سكربت. فقط bun run له.
  • التوافق مع الإصدارات السابقة — لأن Bun لا يزال يحترم الإصدارات المحددة في package.json إذا كان موجوداً، يمكنك التبديل إلى قرار أسلوب Bun بأمر واحد: rm -rf node_modules.

القيود

  • لا Intellisense. الإكمال التلقائي لـ TypeScript في IDEs يعتمد على وجود ملفات إعلان النوع داخل node_modules. نحن نبحث في حلول مختلفة لهذا.
  • لا دعم لـ patch-package

الأسئلة الشائعة

كيف يختلف هذا عما يفعله pnpm؟">

مع pnpm، يجب تشغيل pnpm install، الذي ينشئ مجلد node_modules من symlinks ليقوم وقت التشغيل بحلها. على النقيض، يحل Bun الاعتماديات على الطاير عند تشغيل ملف؛ لا حاجة لتشغيل أي أمر install مسبقاً. Bun أيضاً لا ينشئ مجلد node_modules.

كيف يختلف هذا عما يفعله Yarn Plug'N'Play؟">

مع Yarn، يجب تشغيل yarn install قبل تشغيل سكربت. على النقيض، يحل Bun الاعتماديات على الطاير عند تشغيل ملف؛ لا حاجة لتشغيل أي أمر install مسبقاً.

يستخدم Yarn Plug'N'Play أيضاً ملفات zip لتخزين الاعتماديات. هذا يجعل تحميل الاعتماديات أبطأ في وقت التشغيل، حيث تميل قراءات الوصول العشوائي على ملفات zip إلى أن تكون أبطأ من البحث المكافئ على القرص.

كيف يختلف هذا عما يفعله Deno؟">

يتطلب Deno محدد npm: قبل كل import لـ npm، ويفتقر إلى دعم خرائط الاستيراد عبر compilerOptions.paths في tsconfig.json، ولديه دعم غير مكتمل لإعدادات package.json. على عكس Deno، لا يدعم Bun حالياً عمليات استيراد URL.

Bun بواسطة www.bunjs.com.cn تحرير