Vite 6 در ۲۶ نوامبر ۲۰۲۴ منتشر شد و Environment API آزمایشی را برای سازندگان framework و ابزار مطرح کرد. این انتشار را نباید با Vite 8 اشتباه گرفت که در مارس ۲۰۲۶ با Rolldown به‌عنوان bundler یکپارچه معرفی شد. اعلام رسمی نسخه 6 و اعلام نسخه 8 تفاوت را روشن می‌کنند. متن قبلی جایگزینی Rollup با Rolldown و افزایش سرعت عمومی را به Vite 6 نسبت داده بود؛ آن ادعاها مبنای این راهنما نیستند.
برای کار روزمره، Vite نقش محیط توسعه و ساخت خروجی برنامه را دارد. Router، سیستم احراز هویت یا پایگاه داده را به‌طور خودکار فراهم نمی‌کند. اگر یک framework روی Vite بنا شده، امکانات همان framework را از امکانات خود Vite جدا بخوانید. این تفکیک وقتی مهم می‌شود که تنظیم یا خطای پروژه را بررسی می‌کنید؛ هر مسئله‌ای در یک پروژه Vite-based به خود Vite مربوط نیست.
Dev Server و build دو مرحله متفاوت‌اند
در توسعه، تغییر فایل باید زود در محیط کار دیده شود. خروجی استقرار باید منابع لازم را برای تحویل به مرورگر آماده کند. این دو هدف، نیازهای متفاوتی دارند. موفق بودن صفحه در Dev Server ثابت نمی‌کند مسیر منابع یا تنظیمات خروجی استقرار درست است. تیم باید بداند کدام فرمان برای کار روزانه است و کدام فرمان فایل‌های قابل انتشار را می‌سازد.
HMR به تازه شدن بخش‌های مرتبط برنامه هنگام تغییر کد کمک می‌کند. با این حال حفظ وضعیت component یا رفتار دقیق آن به integration و framework هم وابسته است. وقتی مشکلی فقط بعد از تغییر فایل دیده می‌شود، یک بار مسیر راه‌اندازی کامل را از همان حالت خاص تفکیک کنید. نباید رفتار محیط توسعه را قرارداد قطعی اجرای Production فرض کرد.
فایل index.html در پروژه ساده Vite نقطه ورود است و به module اصلی اشاره می‌کند. این ساختار با پروژه‌ای که صفحه را روی سرور تولید می‌کند یکسان نیست. در SSR، بخشی از کد در محیطی بدون DOM اجرا می‌شود. دسترسی بی‌شرط به document یا window در module مشترک می‌تواند مشکل ایجاد کند؛ محل اجرای کد را قبل از افزودن کتابخانه مرورگرمحور مشخص کنید.
Environment API برای چه کسی بود؟
در Vite 6، Environment API به سازندگان framework و plugin اجازه می‌داد محیط‌های اجرا را با مدل روشن‌تری مدیریت کنند. استفاده معمول از یک SPA به بازنویسی پروژه با این API نیاز نداشت. راهنمای Environment API نسخه 6 وضعیت آزمایشی و مخاطب آن را توضیح می‌دهد. یک عنوان تازه در خبر انتشار، دستور اضافه کردن پیچیدگی به تمام پروژه‌ها نیست.
یک framework ممکن است محیط client، محیط رندر سرور و محیط اجرا روی Runtime دیگری داشته باشد. هر کدام قواعد resolve و اجرای خود را دارند. Pluginی که فقط یک فرایند Node را فرض گرفته است، شاید در چنین ترکیبی رفتار مناسبی نداشته باشد. برای نگهدارنده ابزار، دانستن محیط فعلی مهم است؛ برای مصرف‌کننده framework، استفاده از تنظیم پشتیبانی‌شده آن معمولاً نقطه شروع مناسب‌تری است.
اگر plugin می‌نویسید، دامنه کار آن را مستند کنید. آیا فقط فایل را transform می‌کند یا کدی در محیط اجرا می‌سازد؟ آیا به فایل سیستم توسعه‌دهنده دسترسی دارد؟ آیا خروجی مخصوص client را به سرور هم تحویل می‌دهد؟ پاسخ روشن این سؤال‌ها به دیگران کمک می‌کند محدودیت ابزار را پیش از ترکیب با پروژه چندمحیطی بفهمند.
نمونه کامل بدون framework
نمونه زیر یک صفحه فارسی با شمارنده است. HTML، CSS و JavaScript همگی ارائه شده‌اند و به تصویر، API یا بسته دیگری وابسته نیستند. برای آشنایی با خانواده Vite 6 نوشته شده و توصیه‌ای برای آغاز پروژه جدید روی نسخه قدیمی نیست. پروژه تازه باید نسخه پشتیبانی‌شده را با نیاز framework انتخاب کند. در پروژه آموزشی این مثال، فایل package.json زیر را در پوشه‌ای خالی قرار دهید.
{
"name": "vite-counter-example",
"private": true,
"type": "module",
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview"
},
"devDependencies": { "vite": "^6.0.0" }
}
یک نسخه پشتیبانی‌شده Node.js که با Vite 6 سازگار است نصب کنید و راهنمای نسخه را برای پیش‌نیازها بخوانید. سپس npm install وابستگی ثبت‌شده را نصب می‌کند و package-lock.json را می‌سازد. آن فایل را برای نصب قابل تکرار نگه دارید. وابستگی Vite در devDependencies قرار دارد، چون مرورگر خروجی build را مصرف می‌کند، نه خود Dev Server را.
فایل index.html زیر به src/main.js اشاره دارد. عنوان، محدوده اصلی، دکمه و خروجی شمارنده همگی در HTML موجودند؛ JavaScript لازم نیست ساختار صفحه را از صفر حدس بزند. dir و lang فارسی را تعیین می‌کنند. متن خروجی با aria-live تغییر می‌کند تا اعلام تغییر برای فناوری کمکی امکان‌پذیر باشد، ولی نرخ اعلام در قابلیت‌های پر تغییر باید جدا طراحی شود.
<!doctype html>
<html lang="fa" dir="rtl">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>شمارنده آموزشی</title>
</head>
<body>
<main class="counter">
<h1>شمارنده آموزشی</h1>
<p>مقدار فعلی: <output id="count" aria-live="polite">0</output></p>
<button id="increment" type="button">افزایش مقدار</button>
</main>
<script type="module" src="/src/main.js"></script>
</body>
</html>
پوشه src را بسازید و main.js زیر را در آن قرار دهید. Import فایل CSS ارتباط واضحی میان entry و style ایجاد می‌کند. این کد فقط مقدار آموزشی شمارنده را در حافظه همین صفحه نگه می‌دارد. تازه کردن صفحه آن را به صفر برمی‌گرداند؛ نمونه، ذخیره‌سازی پایدار یا همگام‌سازی میان کاربران ندارد.
import "./style.css";
const button = document.getElementById("increment");
const output = document.getElementById("count");
let count = 0;
button.addEventListener("click", () => {
count += 1;
output.textContent = String(count);
});
فایل src/style.css کلاس‌های استفاده‌شده در همان HTML را پوشش می‌دهد. عرض محتوا محدود شده ولی دکمه در صفحه کوچک همچنان در دسترس است. از نام کلاس جدید بدون markup متناظر استفاده نشده است. در پروژه بزرگ‌تر، styleهای مشترک و style یک component را با قرارداد مشخص جدا کنید تا تغییر یک صفحه به شکل ناخواسته صفحات دیگر را عوض نکند.
body { margin: 0; font-family: sans-serif; background: #f3f4f6; color: #18212b; }
.counter { max-width: 36rem; margin: 3rem auto; padding: 2rem; background: white; line-height: 1.8; }
button { font: inherit; padding: .6rem 1rem; border: 1px solid #18212b; border-radius: .4rem; background: #18212b; color: white; cursor: pointer; }
button:focus-visible { outline: 3px solid #1262bc; outline-offset: 3px; }
@media (max-width: 40rem) { .counter { margin: 1rem; padding: 1rem; } }
npm run dev محیط توسعه را آغاز می‌کند. با npm run build خروجی در dist ساخته می‌شود و npm run preview برای مرور محلی همان خروجی است. Preview جای سرور Production یا راهبرد عملیات نیست. برای انتشار این برنامه static، فایل‌های dist را به میزبان فایل static تحویل می‌دهید. در یک framework دارای SSR، روش انتشار به adapter و محیط همان framework وابسته است.
Environment Variable راز سمت سرور نیست
Vite مقدارهایی با پیشوند VITE_ را برای استفاده در کد client در دسترس می‌گذارد. این مقدارها می‌توانند وارد خروجی مرورگر شوند. کلید خصوصی API یا رمز پایگاه داده را در چنین متغیری نگذارید. راهنمای Env Variables and Modes مرجع تفاوت mode، فایل‌های env و جایگزینی مقدارهاست. اسم فایل env به تنهایی محرمانگی داده را تضمین نمی‌کند.
مقداری مانند نشانی عمومی سرویس با راز دسترسی فرق دارد. اگر مرورگر باید آن نشانی را برای درخواست ببیند، پنهان کردن آن هدف معناداری نیست. مجوز دسترسی و راز باید در لایه مناسب سرور مدیریت شوند. در بازبینی کد، مسیر داده را دنبال کنید: متغیر کجا خوانده می‌شود و خروجی آن به چه کسی می‌رسد؟ این روش از اتکا به نام‌هایی مانند secret در یک فایل client بهتر است.
مسیر منابع و base را پیش از انتشار روشن کنید
اگر برنامه در زیرمسیر یک دامنه منتشر می‌شود، آدرس منابع باید با همان محل هماهنگ باشد. تنظیم base به این مسئله مربوط است. راهنمای Building for Production روش تنظیم و محدودیت‌های خروجی را توضیح می‌دهد. برنامه‌ای که در ریشه دامنه توسعه می‌یابد ممکن است پس از نصب در یک زیرمسیر، منابع را از نشانی اشتباه بخواهد.
در یک SPA، مسیرهای client و fallback میزبان نیز به هم وابسته‌اند. کلیک داخل برنامه ممکن است کار کند ولی باز کردن مستقیم همان URL پاسخ مناسبی ندهد. این مسئله را با base اشتباه نگیرید؛ یکی به منابع و دیگری به مسیریابی و پاسخ میزبان مربوط است. ساختار URLهای محصول باید در مستند انتشار نوشته شود تا تیم عملیات مجبور نباشد رفتار Router را حدس بزند.
ارتقا را با نقشه وابستگی انجام دهید
پیش از تغییر major، framework، pluginها، نسخه Node و تنظیمات build را ثبت کنید. ممکن است پروژه مستقیماً Vite را مدیریت نکند و نسخه آن از framework بیاید. ارتقای دستی یک وابستگی زیرین بدون هماهنگی framework، ترکیب پشتیبانی‌نشده می‌سازد. تغییر را در محدوده‌ای انجام دهید که علت تفاوت خروجی مشخص بماند و روش بازگشت واضح باشد.
Rolldown در Vite 8 بخشی از معماری اصلی شده است، اما نتیجه یک benchmark را برای همه پروژه‌ها تعمیم ندهید. زمان build تحت تأثیر plugin، اندازه پروژه و کارهای جانبی نیز هست. فایل بزرگ خروجی هم صرفاً با سریع‌تر شدن bundler کوچک نمی‌شود. برای مدیریت حجم و هزینه اجرای مرورگر، مقاله Performance Budget موضوع مرتبط‌تری است.
برای هماهنگ کردن نصب و ساخت در تیم، فرمان‌ها را در package.json نگه دارید و مراحل pipeline را روشن کنید. مقاله CI/CD پروژه‌های فرانت‌اند به این گردش کار مربوط است. قدم بعدی برای پروژه موجود، تهیه فهرست نسخه‌های واقعی و جدا کردن مسئله محیط توسعه از مسئله خروجی Production است؛ بعد می‌توان درباره ارتقا یا تغییر تنظیمات تصمیم دقیق‌تری گرفت.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!