mise, Nix و devcontainers يحلون جميعاً مشكلة "يعمل على جهازي" — فقط يختلفون حول الطريقة

عبارة "يعمل على جهازي" تطارد فرق البرمجيات لعقود. ينضم موظف جديد، يقضي يومين في إعداد بيئته. مطور كبير يرقّي Python، فيُفسد ثلاثة مشاريع. يفشل CI بسبب إصدار مكتبة لم يثبّتها أحد. السبب الجذري دائمًا واحد: بيئات المطورين حالتية، ضمنية، ويتم تجميعها يدويًا.

في عام 2026، تم حل هذه المشكلة حقًا — ولكن "حُلّت" تعني ثلاث أدوات منافسة بفلسفات مختلفة جذريًا. فهم المقايضات هو المهارة الحقيقية.

المستوى 1 — mise: نقطة البداية العملية

mise (المعروف سابقًا بـ rtx) هو مدير إصدارات متعدد اللغات مكتوب بلغة Rust. يحل محل asdf مع كونه أسرع بـ 10–20 مرة بفضل نواته المُجمعة وحل الإضافات المتوازي. يتعامل مع Node.js وPython وGo وRuby وJava وعشرات من بيئات التشغيل الأخرى من أداة واحدة.

الآلية الأساسية هي ملف .mise.toml في جذر المشروع:

[tools]
node = "22.3.0"
python = "3.12.4"
go = "1.22.5"

[env]
DATABASE_URL = "postgres://localhost/myapp_dev"

قم بتشغيل mise install فيقرأ التكوين، ويحمل الإصدارات المثبتة إلى ذاكرة تخزين مؤقتة محلية موجهة بالمحتوى (~/.local/share/mise/installs/)، وينشطها للدليل الحالي. لا تلاعب بالروابط الرمزية، ولا حيل shell تتجاوز إضافة mise activate إلى ملفك الشخصي.

الفرق في الأداء عن asdf ليس طفيفًا. تثبيت إصدار Node.js يستغرق asdf 45 ثانية لحله وتثبيته، بينما يكمله mise في أقل من 4 ثوانٍ. بالنسبة للفرق التي تتنقل باستمرار بين مشاريع بمتطلبات بيئة تشغيل مختلفة، يترجم هذا إلى توفير حقيقي في الوقت.

ما لا يفعله mise: يدير بيئات تشغيل اللغة، وليس مكتبات النظام. إذا كان مشروعك يحتاج إصدارًا معينًا من libpq أو openssl أو ffmpeg، لا يمكن لـ mise المساعدة. كما لا يمكنه إعادة إنتاج إصدار glibc الدقيق على Linux أو سلسلة أدوات Xcode الدقيقة على macOS. بالنسبة لمعظم مطوري التطبيقات، هذه الفجوات لا تهم. للباقي، تابع القراءة.

المستوى 2 — Nix و Nix Flakes: قابلية التكرار الكاملة

Nix هو مدير حزم تابعي مبني حول فكرة واحدة: كل حزمة هي دالة خالصة لمدخلاتها. بنفس المدخلات، تحصل دائمًا على نفس المخرجات. تعيش الحزم في /nix/store/ تحت مسارات موجهة بالمحتوى مثل /nix/store/ybmrfz0-nodejs-22.3.0/. يمكن لحزمتين الاعتماد على إصدارات مختلفة من نفس المكتبة دون تعارض لأنهما تقعان حرفيًا في مسارات مختلفة.

nixpkgs هو مستودع الحزم: أكثر من 90,000 حزمة، جميعها مبنية بشكل قابل للتكرار، وتغطي كل نظام بيئي رئيسي للغات بالإضافة إلى أدوات النظام والخطوط وقواعد البيانات والمترجمات. إنها أكبر مجموعة حزم مصدر واحد لأي توزيعة Linux.

Nix flakes (المستقرة في NixOS 23.11) تضيف نموذج اعتماديات قائم على lockfile إلى Nix نفسه. ملف flake.nix في جذر المشروع يثبت commit nixpkgs الدقيق ويُعرِّف devShell:

{
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.05";

  outputs = { self, nixpkgs }: {
    devShells.x86_64-linux.default = nixpkgs.legacyPackages.x86_64-linux.mkShell {
      packages = with nixpkgs.legacyPackages.x86_64-linux; [
        nodejs_22
        python312
        go_1_22
        postgresql_16
        ffmpeg
      ];
    };
  };
}

قم بتشغيل nix develop وستدخل إلى shell حيث كل أداة محددة تمامًا — وصولاً إلى إصدارات مكتبة C. ملف flake.lock يثبت SHA commit nixpkgs. بعد ستة أشهر، على جهاز مختلف، في بلد مختلف، nix develop يُنتج نفس البيئة.

منحنى التعلم الصادق: لدى Nix لغته الوظيفية الخاصة (تسمى أيضًا Nix)، ونموذجه العقلي الخاص لكيفية عمل البناء، ووثائق تفترض الإلمام بمفاهيم البرمجة الوظيفية. معظم المطورين يقضون 1-2 أسابيع قبل أن يشعروا بالراحة في كتابة flakes من الصفر. أدوات مثل devenv.sh و flake-parts تقلل هذا بشكل كبير، لكن لا يوجد اختصار حول المفاهيم الأساسية.

العائد حقيقي. الفرق التي تستخدم Nix flakes تبلغ عن عدم وجود مشكلات "انحراف البيئة" في تقارير ما بعد الحادث. CI يشغل نفس shell nix develop المستخدم في التطوير المحلي. الموظفون الجدد يشغلون nix develop في اليوم الأول ولديهم بيئة عمل في دقائق، لا أيام.

المستوى 3 — devcontainers: الإعداد والتطوير السحابي الأول

devcontainers هو مواصفة مفتوحة (مدعومة من Microsoft ومستخدمة في VS Code وGitHub Codespaces) تعرف بيئة التطوير كحاوية Docker. التكوين موجود في .devcontainer/devcontainer.json:

{
  "name": "My Project",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "features": {
    "ghcr.io/devcontainers/features/python:1": { "version": "3.12" },
    "ghcr.io/devcontainers/features/go:1": { "version": "1.22" }
  },
  "postCreateCommand": "npm install",
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
    }
  }
}

إضافة Remote - Containers في VS Code تقوم بتركيب ملفاتك المحلية في الحاوية وتشغل محررك بالكامل داخلها — خوادم اللغة، المصححات، المحطات الطرفية، جميعها تعمل في بيئة الحاوية. GitHub Codespaces يأخذ هذا أبعد: انقر على "Open in Codespaces" وبيئة التطوير بأكملها تعمل على البنية التحتية السحابية لـ GitHub، وليس على حاسوبك المحمول.

أين تتفوق devcontainers: الإعداد بنقرة واحدة حقًا. العزل الأمني حقيقي — نظام ملفات الحاوية منفصل عن المضيف. للمهام كثيفة الحساب (تدريب النماذج الكبيرة، عرض الفيديو، تجميع قواعد C++ الضخمة)، يعد التفريغ إلى Codespaces مع أجهزة سحابية بـ 32 نواة إنتاجية حقيقية.

أين تكافح devcontainers: عبء Docker حقيقي على macOS. أداء نظام الملفات عبر طبقة VM الخاصة بـ Docker يمكن أن يكون أبطأ 2-3 مرات من الأداء الأصلي للمهام كثيفة I/O مثل تشغيل مجموعة اختبار كبيرة. أنت أيضًا تعتمد على اتصال الشبكة وتشغيل Docker — ولا شيء مضمون في جميع سياقات التطوير.

كيف تجمع الفرق الحقيقية بين هذه الأدوات

الخيار الخاطئ هو اختيار أداة والمضي قدمًا بشكل كامل. الفرق التي فهمت هذا عادةً ما تقوم بطبقات:

• mise للتبديل اليومي بين اللغات. كل مطور يمتلكه. يتعامل مع 90% من أسئلة "أي إصدار من Node/Python/Go" بأقل احتكاك. يتم رفع .mise.toml إلى المستودع.
• Nix flakes للفرق ذات المتطلبات على مستوى النظام. إذا كنت بحاجة لإصدارات محددة من المكتبات الأصلية، أو إذا كنت تبني على كل من Linux وmacOS وتحتاج بيئات متطابقة، فإن flake.nix يستحق الاستثمار. بعض الفرق تستخدم Nix فقط لـ CI، لتحقيق قابلية التكرار حيثما تكون أكثر أهمية.
• devcontainers للإعداد والتوافق مع CI. يتم الاحتفاظ بتكوين .devcontainer/ لليوم الأول للموظف الجديد وللوصول إلى GitHub Codespaces. لا يحل محل أدوات التطوير المحلية لكنه يوفر خيارًا احتياطيًا مضمونًا.

مثال ملموس: فريق من 12 مطورًا يستخدم mise محليًا للتبديل السريع للإصدارات، وNix flakes في CI (GitHub Actions تشغل nix develop --command make test)، وdevcontainer للوصول إلى Codespaces عندما يكون أعضاء الفريق مسافرين أو على أجهزة شركة مقيدة.

المقايضات الصادقة

• mise: يتم تثبيته في 30 ثانية، يعمل في كل مكان، يتعامل مع 90% من المشاكل الحقيقية، ولكن لا يمكنه إدارة مكتبات النظام أو ضمان قابلية التكرار الثنائي تحت مستوى بيئة تشغيل اللغة.
• Nix: أقوى خيار متاح، ينتج بيئات قابلة للتكرار بتًا مقابل بت، يغطي كل طبقة من المكدس، لكنه يتطلب استثمارًا حقيقيًا للتعلم ويمكن أن يجعل المهام البسيطة (إضافة تبعية حزمة جديدة) تبدو ثقيلة حتى تترسخ المفاهيم.
• devcontainers: أقل حاجز لدخول الإعداد، سحابي أصلي، أصلي في VS Code، لكنه يحمل عبء Docker، ويتطلب الاتصال، ويمكن أن يحجب تفاصيل البيئة بطرق تجعل التصحيح أصعب.

من أين تبدأ

إذا كان فريقك يضم أقل من 5 مطورين والألم هو "الجميع على إصدارات مختلفة من Node/Python": قم بتثبيت mise اليوم، ورفع .mise.toml، وانتهى الأمر. ستصلح 90% من شكاوى البيئة في فترة ما بعد الظهر.

إذا كان فريقك يضم 10 مطورين أو أكثر، وتقوم بالتسليم إلى Linux، ولديك تبعيات مكتبة أصلية، وتسبب انحراف البيئة في حوادث إنتاجية حقيقية: استثمر في Nix flakes. خصص 2-3 أسابيع ليطور مطور واحد خبرته في Nix ليصبح خبير الفريق. العائد حقيقي.

إذا كان ألمك الأساسي هو وقت الإعداد، أو تعمل بشكل كبير مع GitHub، أو تحتاج إلى عزل آمن للمتعاقدين: devcontainers هي الرافعة الصحيحة. تتكامل بشكل جيد مع كل من mise وNix — يمكنك تشغيل mise داخل devcontainer، أو بناء صورة devcontainer من اشتقاق Nix.

مشكلة "يعمل على جهازي" قد حُلَّت. السؤال المتبقي هو أي حل يناسب القيود الفعلية لفريقك — وهل أنت مستعد لدفع تكاليف التعلم التي تتطلبها الخيارات الأكثر قوة.