Bun مقابل Deno
Bun (بيئة تشغيل مبنية على Zig، أسرع بثلاث مرات) مقابل Deno (بيئة تشغيل مبنية على Rust، تركز على TypeScript) — مقارنة بدائل Node.js الحديثة. الأداء، التوافق، النظام البيئي.
مخزن قابل للعنونة بالمحتوى، عزل صارم، مراجعة ناضجة لسلسلة التوريد
نواة مكتوبة بلغة Rust، سريعة، مكوّن التثبيت في بيئة تشغيل Bun الموحّدة
لا يوجد فائز حاسم؛ فالأداتان تُحسَّنان لأولويات مختلفة. إذا كنت تريد البقاء مستقلًا عن بيئة التشغيل (runtime) ومراجعة السياسة في كل أمر يُعدّل lockfile، فاختر pnpm. أما إذا كنت تستخدم Bun بالفعل كبيئة تشغيل ومكسب المخزن الافتراضي العالمي في المساحة والسرعة أمر حاسم بالنسبة لك، فإن bun install خيار جذاب. كلتاهما تحظران postinstall افتراضيًا؛ الفرق يكمن في مكان نقاط المراجعة. لا تخلط بينهما في نفس المستودع — مصدر حقيقة واحد، ملف lockfile واحد.
| الفئة | pnpm | bun install |
|---|---|---|
| الأداء | 8/10 | 9/10 |
| سهولة التعلّم | 7/10 | 8/10 |
| النظام البيئي | 9/10 | 6/10 |
| المجتمع | 8/10 | 7/10 |
| سوق العمل | 7/10 | 6/10 |
| الاستدامة المستقبلية | 8/10 | 8/10 |
// pnpm 12.3 — تثبيت مُراجَع مع allowBuilds وتصفية workspace
// package.json (الجذر)
{
"name": "monorepo-root",
"private": true,
"packageManager": "[email protected]"
}
// pnpm-workspace.yaml — وصل allowBuilds في v10.26.0؛ وأزال v11 الأسماء القديمة (onlyBuiltDependencies وغيرها)
packages:
- "apps/*"
- "packages/*"
allowBuilds:
esbuild: true
sharp: true
core-js: false
catalog:
react: ^19.2.3
typescript: ^5.7.0
// خطوة التثبيت في CI (GitHub Actions)
- name: Install dependencies
run: pnpm install --frozen-lockfile --trust-policy=no-downgrade
// عند إزالة حزمة، يُعاد التحقق من ملف lockfile بأكمله في مقابل السياسات الفعّالة
pnpm remove left-pad --filter ./apps/web --trust-lockfile
// تثبيت فقط لحزم workspace التي تغيّرت
pnpm install --filter "...[origin/main]"
// معرفة موقع المخزن لإضافته إلى مفتاح cache في CI
pnpm store path// Bun 1.4 — isolated installs + المخزن الافتراضي العالمي + تثبيت غير متصل بالشبكة
// bunfig.toml (الجذر)
[install]
linker = "isolated"
globalStore = true
exact = false
// package.json
{
"name": "monorepo-root",
"private": true,
"workspaces": ["apps/*", "packages/*"],
"trustedDependencies": [
"esbuild",
"sharp",
"@prisma/client"
]
}
// خطوة التثبيت في CI (GitHub Actions) — مقفلة ومتوافقة مع وضع عدم الاتصال
- name: Install dependencies
run: bun install --frozen-lockfile --prefer-offline
// عرض نصوص postinstall المحظورة
bun pm untrusted
// وضع علامة الثقة على حزمة
bun pm trust sharp
// تثبيت لحزم workspace محددة
bun install --filter "./apps/web"
// تثبيت كامل غير متصل بالشبكة (لا يخرج إلى الشبكة إطلاقًا)
bun install --offlineلا يوجد فائز حاسم؛ فالأداتان تُحسَّنان لأولويات مختلفة. إذا كنت تريد البقاء مستقلًا عن بيئة التشغيل (runtime) ومراجعة السياسة في كل أمر يُعدّل lockfile، فاختر pnpm. أما إذا كنت تستخدم Bun بالفعل كبيئة تشغيل ومكسب المخزن الافتراضي العالمي في المساحة والسرعة أمر حاسم بالنسبة لك، فإن bun install خيار جذاب. كلتاهما تحظران postinstall افتراضيًا؛ الفرق يكمن في مكان نقاط المراجعة. لا تخلط بينهما في نفس المستودع — مصدر حقيقة واحد، ملف lockfile واحد.
احصل على استشارة مجانيةيختلف الأمر حسب السيناريو. القياس الذي نشرته Bun هو بين أدوات الربط (linker) الخاصة بها: في مشروع تجريبي يضم 1,400 حزمة (React/webpack/Babel/jest)، استغرق التثبيت الساخن 823.9 مللي ثانية مع linker من نوع hoisted، مقابل 124.8 مللي ثانية مع isolated linker + المخزن العالمي (Apple Silicon macOS، hyperfine). كذلك يعتمد مخزن pnpm القابل للعنونة بالمحتوى (content-addressable store) على القراءة من القرص في التثبيتات الساخنة، أي أن كلتا الأداتين سريعتان في الظروف المناسبة. الفرق الحقيقي بينهما يجب قياسه في مستودعك الخاص وبإستراتيجية cache الخاصة بـCI لديك — لا تُسقِط نتيجة قياس واحد على مستودعك.