Next.js 16.3 Turbopack: وقتی dev server دیگه ۲۱ گیگ رم نمی‌خوره

اگه روی یه پروژه‌ی Next.js بزرگ کار کردی و یه نقطه‌ای رسیدی که Task Manager رو باز کردی و دیدی dev server تنهایی داره ۸ گیگ رم می‌خوره، می‌دونی این احساس چیه. Turbopack از اول با این طراحی اومد که همه‌چیز رو cache کنه تا compile سریع‌تر باشه — ولی قیمتش این بود که هرچقدر بیشتر توی پروژه می‌چرخیدی، حافظه بیشتری می‌خورد و هیچ‌وقت هم آزاد نمی‌کرد.

نسخه‌ی ۱۶.۳ این trade-off رو عوض کرده.

مصرف حافظه: ۹۰ درصد کمتر

تیم Turbopack سه ماه روی این کار کرد. نتیجه چیه؟ روی codebase داشبورد vercel.com، بعد از compile کردن ۵۰ route، مصرف حافظه از ۲۱.۵ گیگابایت به ۲ گیگابایت رسیده — یعنی ۹۰ درصد کمتر. روی سایت nextjs.org هم از ۴۶۰۰ مگابایت به ۸۴۰ مگابایت، یعنی حدود ۸۲ درصد کاهش.

چطور؟ با یه مکانیزم جدید به اسم memory eviction. ایده ساده‌ست: به‌جای اینکه نتایج cache شده برای همیشه توی RAM نگه داشته بشن، حالا Turbopack می‌تونه اونایی که دیگه فعال استفاده نمی‌شن رو بریزه روی دیسک و از حافظه پاک کنه. این feature روی filesystem cache که از نسخه‌ی ۱۶.۱ اضافه شده بود تکیه می‌کنه، و توی ۱۶.۳ هر دو به‌صورت پیش‌فرض فعال هستن.

اگه بخوای غیرفعالش کنی یا رفتارش رو debug کنی:

const nextConfig = {
  experimental: {
    turbopackMemoryEviction: false,
  },
};

یه چیز مهم: عدد دقیق کاهش حافظه برای هر پروژه فرق می‌کنه. بستگی داره به اینکه route graph پروژه‌ات چقدر بزرگه و توی یه session چقدر ازش استفاده کردی.

filesystem cache برای build

تا الان، filesystem cache فقط توی next dev کار می‌کرد. از ۱۶.۳، همین cache برای next build هم در دسترسه.

اعداد رو ببین: روی nextjs.org، build با cache از ۲۱ ثانیه به ۹.۲ ثانیه رسیده — ۲.۳ برابر سریع‌تر. روی vercel.com/geist که یه design system بزرگه، از ۳۰ ثانیه به ۵.۵ ثانیه — یعنی ۵.۵ برابر. روی vercel.com/home که پروژه‌ی سنگین‌تریه، بهبود کمتره: از ۶۶ به ۴۶ ثانیه.

فعال کردنش یه flag می‌خواد:

const nextConfig = {
  experimental: {
    turbopackFileSystemCacheForBuild: true,
  },
};

برای CI هم می‌شه از این استفاده کرد: کافیه پوشه‌ی .next رو بین runها کش کنی. وقتی Turbopack اون دایرکتوری رو اول build پیدا کنه، از کار قبلی استفاده می‌کنه به‌جای اینکه همه‌چیز رو از صفر compile کنه.

React Compiler با Rust

React Compiler از نسخه‌ی ۱۶.۰ توی Next.js stable بوده، ولی تا الان فقط به‌عنوان یه Babel transform اجرا می‌شد. مشکل اینجا بود که Babel روی پروژه‌های بزرگ سنگین می‌شد و build رو کند می‌کرد.

تیم React یه پورت native از این compiler با Rust نوشته، و تیم Turbopack سریع این رو integrate کرده. نتایج اولیه روی پروژه‌هایی مثل v0 نشون می‌ده که compile time بین ۲۰ تا ۵۰ درصد بهتر می‌شه. فعلاً experimental هست:

const nextConfig = {
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};

import.meta.glob

Turbopack حالا از API ای که Vite معروفش کرده پشتیبانی می‌کنه:

const posts = import.meta.glob('./posts/*.mdx');

این به‌جای اینکه مجبور بشی اسم همه‌ی فایل‌ها رو hardcode کنی، هر فایلی که با pattern مطابقت داشته باشه رو import می‌کنه. نتیجه یه object هست که key‌هاش path فایل‌هاست:

for (const path in posts) {
  const post = await posts[path]();
}

می‌تونی با eager: true همه‌شون رو بلافاصله import کنی، یا فقط چند export خاص رو بگیری، یا pattern‌های منفی بگذاری. file watcher هم بهش وصله — اگه فایلی اضافه یا حذف شد، خودش recompile می‌کنه.

یه نکته: این feature فقط روی Turbopack کار می‌کنه. اگه هنوز با --webpack build می‌گیری، اینجا نیست.

HMR سریع‌تر و runtime کوچیک‌تر

دو بهبود دیگه که کمتر headline می‌گیرن ولی در عمل احساس می‌شن: اول اینکه HMR subscription tracking بهتر شده — با یکی کردن چند subscription در جاهایی که قبلاً جداگانه بودن، dev server cold start روی اپ‌های پیچیده بیش از ۱۵ درصد سریع‌تر شده. دوم اینکه runtime code ای که Turbopack به هر route اضافه می‌کنه کوچیک‌تر شده — چون حالا فقط کدی که واقعاً استفاده می‌شه (مثل WebAssembly loader یا worker support) شیپ می‌شه، نه همه‌چیز یکجا.

یه feature کوچیک‌تر هم برای monorepoها اومده: با turbopackLocalPostcssConfig: true می‌تونی per-package پیکربندی PostCSS داشته باشی به‌جای اینکه همه از root config بخوننن.

اگه الان روی Next.js 16.x هستی، این آپدیت شاید مهم‌ترین چیزیه که از نظر DX روزانه حسش می‌کنی — نه یه feature جدید، بلکه اینکه وقتی ساعت‌ها روی پروژه کار می‌کنی، IDE و dev server با هم دیگه دعوا نمی‌کنن سر رم.