Tailwind CSS 4.0 در ۲۲ ژانویهٔ ۲۰۲۵ منتشر شد و مسیر تنظیم پروژه را بیشتر به CSS منتقل کرد. نام Oxide به کار روی موتور تازه مربوط است، اما توصیف «همهٔ Tailwind در Rust بازنویسی شده» دقیق نیست. برای یک تیم توسعه، سؤال کاربردی‌تر این است که نسخهٔ چهارم چه تغییری در ساخت CSS، تعریف Theme و نگهداری کلاس‌ها ایجاد می‌کند. خبر انتشار را باید از تصمیم مهاجرت جدا کرد؛ منتشر شدن نسخهٔ تازه، به‌تنهایی دلیل تغییر یک پروژهٔ پایدار نیست.
در اعلام رسمی نسخهٔ چهارم، تیم Tailwind نتایج اندازه‌گیری موتور تازه را برای سناریوهای مشخص خود گزارش کرده است. این اعداد تضمین سرعت یک پروژهٔ دیگر نیستند. ادعای قبلی این مقاله دربارهٔ ده برابر شدن همیشگی سرعت، مهاجرت سی‌دقیقه‌ای و انجام خودکار بیش از نود درصد تغییرات، پشتوانهٔ مشخصی نداشت و حذف شده است. زمان مهاجرت به وابستگی‌ها، میزان سفارشی‌سازی و تفاوت خروجی مورد انتظار بستگی دارد.
تغییر اصلی در کار روزمره
در بسیاری از پروژه‌ها می‌توان ورودی CSS را با import کردن Tailwind آغاز کرد و تنظیم‌های طراحی را کنار همان ورودی نوشت. این ترتیب برای طراح و توسعه‌دهنده‌ای که رنگ‌ها و فاصله‌های پروژه را مرور می‌کنند روشن‌تر است: تصمیم طراحی در فایل مرتبط با ظاهر دیده می‌شود. حذف نیاز به یک فایل تنظیم جدا در شروع ساده، به معنی بی‌نیازی از قرارداد طراحی نیست. هنوز باید مشخص کنید کدام رنگ، اندازه و فاصله مجاز است و چه کسی آن را تغییر می‌دهد.
اگر پروژهٔ قبلی تنظیم JavaScript دارد، نباید آن را بدون بررسی کنار بگذارید. ممکن است pluginها یا تصمیم‌های طراحی در همان فایل باشند. مهاجرت خوب با فهرست کردن ورودی‌ها آغاز می‌شود: فایل CSS، تنظیم‌های قبلی، ابزار build و مسیر فایل‌هایی که class دارند. بعد می‌توان تصمیم گرفت هر مورد چگونه به شکل تازه منتقل شود. این فهرست کوتاه از ارتقایی که فقط package را تغییر می‌دهد و انتظار دارد همه‌چیز خودکار حل شود، قابل پیگیری‌تر است.
یک نمونهٔ کوچک با Tailwind CLI
مثال این مقاله یک صفحهٔ معرفی خدمات با دو کارت است. فقط Node.js و npm برای نصب ابزار build نیاز دارد؛ React، Vite، تصویر و API در آن استفاده نشده‌اند. در یک پوشهٔ تازه، npm init -y را اجرا کنید و سپس با npm install -D tailwindcss@4 @tailwindcss/cli@4 دو وابستگی را نصب کنید. عدد چهار در فرمان، خانوادهٔ نسخهٔ مورد بحث را انتخاب می‌کند. برای ثبت نسخهٔ دقیق نصب‌شده، فایل lock پروژه را نگه دارید.
فایل input.css را در ریشهٔ همان پوشه با محتوای زیر بسازید. Theme نمونه فقط یک رنگ اختصاصی دارد. نام آن مشخص است و قرار نیست معنای همهٔ رنگ‌های پروژه را عوض کند. فایل output.css خروجی ابزار خواهد بود و نباید با دست ویرایش شود؛ تغییر دستی در آن با build بعدی از بین می‌رود. تفاوت فایل منبع و خروجی را از ابتدا برای اعضای تیم روشن کنید.
@import "tailwindcss";
@theme {
--color-brand-700: #2447a8;
}
فایل index.html نیز در همان پوشه قرار می‌گیرد. کلاس‌های کانتینر روی main و بخش grid نوشته شده‌اند و هر کارت یک article مستقل است. تعداد کارت‌های توضیح داده‌شده با تعداد عناصر نمونه برابر است. صفحه عمداً یک ساختار کوچک دارد تا رابطهٔ utilityها با HTML دیده شود؛ آن را به‌عنوان طرح نهایی یک برند یا معیار کیفیت رابط در نظر نگیرید.
<!doctype html>
<html lang="fa" dir="rtl">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>دو کارت خدمات</title>
<link rel="stylesheet" href="./output.css">
</head>
<body class="bg-slate-50 text-slate-900">
<main class="mx-auto max-w-4xl px-6 py-12">
<h1 class="text-3xl font-bold">خدمات طراحی</h1>
<div class="mt-8 grid gap-6 sm:grid-cols-2">
<article class="rounded-xl border border-slate-300 bg-white p-6">
<h2 class="text-xl font-semibold text-brand-700">طراحی صفحه</h2>
<p class="mt-3 leading-8">ساختار محتوا و مسیر دسترسی مخاطب را مشخص کنید.</p>
</article>
<article class="rounded-xl border border-slate-300 bg-white p-6">
<h2 class="text-xl font-semibold text-brand-700">مرور رابط</h2>
<p class="mt-3 leading-8">حالت‌های خالی و خطا را همراه جریان اصلی بررسی کنید.</p>
</article>
</div>
</main>
</body>
</html>
اکنون فرمان npx @tailwindcss/cli -i ./input.css -o ./output.css --watch را در همان پوشه اجرا کنید. ابزار ورودی CSS را می‌خواند و فایل خروجی را کنار آن می‌سازد. بعد index.html را باز کنید. تغییر کلاس‌ها در HTML باید در فرایند watch به خروجی تازه منجر شود. این دستور روش اجرای نمونه است؛ گزارش سرعت اندازه‌گیری‌شده یا ادعای آزمون روی همهٔ مرورگرها نیست. راهنمای نصب رسمی Tailwind CLI مسیر نصب و build را توضیح می‌دهد.
Theme را به زبان محصول تعریف کنید
رنگ brand در نمونه یک تصمیم فرضی برای همان صفحه است. در پروژهٔ واقعی، «اصلی»، «خطر» و «سطح پس‌زمینه» ممکن است معنای متفاوتی داشته باشند. بهتر است تیم دربارهٔ نقش رنگ توافق کند و بعد نام فنی آن را انتخاب کند. اگر یک رنگ هم برای دکمهٔ خرید و هم برای خطای فرم استفاده می‌شود، مسئله با تغییر نام utility حل نمی‌شود؛ معنای بصری نیاز به بازبینی دارد. نام‌گذاری باید به این بازبینی کمک کند.
Theme variables در نسخهٔ چهارم به CSS custom properties مرتبط‌اند و قرارداد آن‌ها بر utilityهای تولیدشده اثر می‌گذارد. برای همین تغییر یک مقدار Theme ممکن است چند بخش رابط را تغییر دهد. صفحهٔ Theme variables در مستندات Tailwind تفاوت تعریف متغیر طراحی با متغیر معمولی CSS را شرح می‌دهد. در یک تیم، بهتر است تغییر Theme همراه با نمونهٔ مصرف آن مرور شود؛ تنها دیدن مقدار جدید رنگ برای فهم پیامد تغییر کافی نیست.
برای یک کارت استثنایی، مقدار arbitrary گاهی مناسب است، اما تبدیل هر فاصله به یک مقدار مستقل، سیستم طراحی را پراکنده می‌کند. وقتی فاصله‌ای در چند صفحه تکرار شد، بررسی کنید که آیا یک تصمیم مشترک است یا شباهتی اتفاقی. افزودن token مشترک باید دلیل داشته باشد. یک فهرست طولانی از نام‌ها که هیچ‌کس معنای آن‌ها را نمی‌داند، نگهداری را آسان نمی‌کند؛ حتی اگر تمام آن‌ها در فایل CSS مرکزی قرار گرفته باشند.
کلاس‌ها باید برای ابزار قابل شناسایی باشند
ساختن نام کلاس با چسباندن رشته‌ها یک دام رایج است. اگر برنامه نام رنگ را از داده بگیرد و داخل یک نام utility بگذارد، ابزار build لزوماً همان کلاس نهایی را در متن فایل پیدا نمی‌کند. مسیر امن‌تر برای مجموعهٔ محدود حالت‌ها، نگاشت هر حالت به رشتهٔ کامل کلاس‌هاست. مثلاً حالت موفق و حالت خطا، هرکدام یک رشتهٔ مشخص داشته باشند. این قرارداد هم قابل خواندن است و هم روشن می‌کند چه حالت‌هایی واقعاً در رابط مجازند.
ورودی کاربران را به نام utility تبدیل نکنید. اگر مدیر محتوا باید رنگ کارت را انتخاب کند، فهرستی از گزینه‌های شناخته‌شده بدهید و در برنامه آن گزینه‌ها را به کلاس‌های مشخص نگاشت کنید. اجازه دادن به رشتهٔ دلخواه، کنترل ظاهر و دامنهٔ تغییر را سخت می‌کند. این مسئله از سرعت موتور build مستقل است. موتور سریع‌تر نمی‌تواند از یک قرارداد دادهٔ مبهم، خروجی قابل پیش‌بینی بسازد. مسئولیت محدود کردن حالت‌ها همچنان با طراحی برنامه است.
مهاجرت را با تفاوت‌های قابل مشاهده پیش ببرید
ابتدا صفحه‌های نماینده را مشخص کنید: فرم، صفحهٔ محتوایی، فهرست کارت‌ها و صفحه‌ای که plugin سفارشی دارد. هدف این انتخاب، پیدا کردن خانواده‌های رفتار است. تعداد زیاد screenshot مشابه لزوماً پوشش بهتری نمی‌دهد. تغییرات breaking در utilityها، defaultها یا شیوهٔ تنظیم باید به همین صفحه‌ها نگاشت شوند تا تیم بداند هر تغییر کجا اثر دارد. اگر پروژه چند بستهٔ مشترک دارد، مسیر مصرف آن بسته‌ها نیز بخشی از مهاجرت است.
ابزار upgrade رسمی برای بخشی از تبدیل‌ها کمک می‌کند، ولی خروجی آن نیاز به مرور دارد. راهنمای رسمی ارتقا محدودیت‌ها و تفاوت‌های نسخه را توضیح می‌دهد. به‌جای وعدهٔ زمان ثابت، مهاجرت را به واحدهای قابل بازگشت تقسیم کنید: ابتدا ابزار build، سپس Theme و بعد موارد ناسازگار. اگر تغییر با بازطراحی کامل رابط مخلوط شود، تشخیص اینکه تفاوت ظاهر از ارتقا آمده یا از تصمیم طراحی تازه، دشوارتر می‌شود.
حداقل مرورگرهای هدف پروژه را پیش از انتخاب نسخهٔ چهارم مشخص کنید. استفاده از قابلیت‌های جدید CSS در خروجی، موضوع سازگاری را به بخشی از تصمیم تبدیل می‌کند. اگر محصول به محیط‌های قدیمی وابسته است، از روی عنوان «نسخهٔ تازه» نتیجه نگیرید که ارتقا مناسب خواهد بود. راهنمای ارتقا مرجع این بررسی است. نگه داشتن نسخهٔ قبلی با دلیل مستند، از مهاجرتی که مخاطب واقعی را از دسترس خارج می‌کند، تصمیم روشن‌تری است.
سرعت build را در جای درست بسنجید
زمان build کامل، build افزایشی و شروع ابزار سه موقعیت متفاوت‌اند. پروژه‌ای که بیشتر منتظر بررسی TypeScript یا bundling JavaScript می‌ماند، ممکن است از سریع‌تر شدن تولید CSS فقط تغییر محدودی احساس کند. اگر تصمیم تیم به سرعت وابسته است، سناریوی اندازه‌گیری را بنویسید: دستگاه، تعداد فایل‌ها، فرمان و اینکه cache گرم است یا سرد. بدون این زمینه، یک عدد سرعت را نمی‌توان به پروژهٔ دیگری منتقل کرد.
برای ادامهٔ کار روی چیدمان، راهنمای Container Queries به تصمیم دربارهٔ رفتار کارت در فضای والد کمک می‌کند. در نمونهٔ حاضر، breakpoint صفحه کافی است و افزودن قابلیت تازه فقط برای نمایش فهرست امکانات ضرورتی ندارد. پس از اجرای مثال، فایل input.css، HTML و lock را نگه دارید و خروجی را با همان فرمان بازتولید کنید. این مسیر کوچک، نقطهٔ شروع مناسبی برای بررسی نسخهٔ چهارم در پروژهٔ خودتان است.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!