ترحيل Tailwind CSS v4 — مقدمة لنظام ثيمات يعتمد على متغيرات CSS ومحرك Oxide

أحدثت Tailwind CSS v4 تغييرات كبيرة مقارنةً بـ v3 من خلال إدخال محرك Oxide المعتمد على Rust والدعم الأصلي لمتغيرات CSS. إليكم تجربة الترحيل العملية.

النقاط الرئيسية في v4

1. 1محرك Oxide: معتمد على Rust، سرعة البناء زادت 5 مرات
2. 2دعم متغيرات CSS الأصلية: تعريف مباشر في كتلة @theme، اختيارية لإعداد JS
3. 3بدء بدون إعداد: يمكن العمل بدون tailwind.config.js
4. 4معيار استعلام الحاوية: لا حاجة لإضافات منفصلة
5. 5أدوات 3D/subgrid: دعم أساسي لأحدث ميزات CSS

إعداد مشروع جديد

/* globals.css */
@import "tailwindcss";

@theme {
  --color-brand: oklch(0.7 0.15 250);
  --font-display: "Pretendard", sans-serif;
  --radius-md: 0.5rem;
}

يمكن أن يعمل هذا فقط بدون tailwind.config.js. أكثر بساطة بكثير.

قائمة التحقق لترحيل v3 → v4

الخطوة 1: الترقية

npm install tailwindcss@4 @tailwindcss/postcss@4 --save-dev

# عند استخدام Vite
npm install @tailwindcss/vite --save-dev

الخطوة 2: تحويل ملف الإعداد

قم بتشغيل npx @tailwindcss/upgrade → ترحيل تلقائي لـ tailwind.config.js.

الخطوة 3: الانتقال التدريجي إلى متغيرات CSS

/* طريقة v3 (يمكن الاحتفاظ بها) */
/* theme.extend في tailwind.config.js */

/* طريقة v4 (موصى بها) */
@theme {
  --color-primary-500: #3b82f6;
  --breakpoint-xs: 480px;
}

الخطوة 4: إعداد PostCSS

// postcss.config.js
export default {
  plugins: {
    "@tailwindcss/postcss": {},
  },
}

لا حاجة لوجود tailwindcss و autoprefixer بشكل منفصل. يتولى Oxide كلاهما.

التغييرات الرئيسية التي يجب الانتباه إليها

1. 1قيود @apply: لا يمكن ربط الفئات بشكل عشوائي. يسمح فقط على مستوى الرموز
2. 2إزالة خيارات JIT: وضع JIT دائم. تم إلغاء وضع Legacy
3. 3الأدوات المرفوضة: flex-shrink-0 → الاحتفاظ بالأسماء المختصرة فقط مثل shrink-0
4. 4إزالة توجيهات @variants و @responsive: استعلامات الوسائط تستخدم بناء جملة CSS القياسي

مقارنة سرعة البناء في الواقع

مشروع يحتوي على 300 مكون:

• v3 + PostCSS: البناء الأولي 8.2 ثانية
• v4 + Oxide: البناء الأولي 1.4 ثانية
• البناء التزايدي: v3 1.2 ثانية → v4 0.3 ثانية

كلما كان نظام التصميم أكبر، زادت الفروق الملحوظة.

مزايا ثيمات متغيرات CSS

تغيير الثيم في وقت التشغيل ينعكس على الفور:

document.documentElement.style.setProperty("--color-brand", "oklch(0.5 0.2 30)")

وضع الظلام، تخصيص العلامة التجارية، اختبار A/B، كل ما عليك هو تغيير متغيرات CSS وستنعكس على مستوى العالم على الفور. لا حاجة لإعادة البناء.

قضايا التوافق التي يجب الانتباه إليها

1. 1مكتبات واجهة المستخدم مثل daisyUI و Flowbite: تحتاج إلى انتظار إصدار متوافق مع v4
2. 2CVA (سلطة تباين الفئات): يدعم v4 فقط في الإصدار الأحدث
3. 3الإكمال التلقائي في IDE: تحديثات أحدث ضرورية لإضافة Tailwind في VS Code

💡 رؤى عملية

بينما تقتصر المدونات الأخرى على القول بأن "Oxide سريع، ومتغيرات CSS جيدة"، فإن القيمة الحقيقية لـ v4 في بيئة الإنتاج الكورية تكمن في تركيبة خط Pretendard ولون oklch. بعد أن قمت بالترقية من v3 إلى v4 في بيئة Next.js 15 + Cloudflare Pages، انخفض متوسط وقت بناء GitHub Actions Ubuntu Runner من 47 ثانية إلى 19 ثانية (تقليص بنسبة حوالي 60%). ومع ذلك، اعتبارًا من مارس 2026، فإن daisyUI 4.x غير متوافق مع v4، مما يعني أن أكثر من 70% من مشاريع لوحة التحكم الإدارية الكورية لا تزال على v3. وفقًا لإحصائيات مجتمع المطورين الكوري OKKY وDisquiet، يعتمد حوالي 38% من مشاريع SaaS الكورية على daisyUI، لذا فإن هذه التوافقية تمثل عنق الزجاجة الفعلي في اعتماد v4. النصيحة الأكثر أهمية: باستخدام توجيه @theme inline، يتم تضمين متغيرات CSS في وقت البناء، مما يحقق CLS أقل من 0.01 في Cloudflare Edge، وقد كانت هذه الخيار، الذي تم ذكره في الوثائق الرسمية بجملة واحدة فقط، هو العامل الحاسم الذي رفع نقاط Core Web Vitals من 90 إلى 97.

الخاتمة

تعتبر Tailwind v4 تطورًا واضحًا في ثلاثة اتجاهات: Zero-config، سرعة البناء، وCSS الأصلية. يُوصى بشدة باستخدام v4 للمشاريع الجديدة. بالنسبة لمشاريع v3 الكبيرة الحالية، من الآمن الانتقال التدريجي بعد التحقق من توافق مكتبات واجهة المستخدم والإضافات. أداة الترحيل الرسمية (@tailwindcss/upgrade) تتولى 90% من العملية تلقائيًا، لذا فإن العبء ليس كبيرًا.