Codoloper

آموزش برنامه‌نویسی به فارسی

یاد بگیر، پیشرفت کن، بساز.

منبع آموزشی برنامه‌نویسی به زبان فارسی - مستندات، دوره‌ها و مطالب کاربردی برای همه سطوح.

داکیومنت ها:

JavascriptJetpack ComposeHTMLCSSبیشتر
1// برنامه‌نویسی به فارسی
2import { learn } from 'codoloper'
3
4const developer = learn({
5"lang": "فارسی"
6"level": "همه سطوح"
7free: true
8})
400+
صفحه مستندات
7+
زبان ها / فریمورک ها
رایگان
دسترسی کامل
چرا کدلپر؟

ارزش‌های ما

یادگیری برنامه‌نویسی نباید پیچیده باشد - ما مسیر را ساده می‌کنیم.

کیفیت بالا
مطالب آموزشی با بالاترین استانداردها تهیه می‌شوند.
همه سطوح
از مبتدی تا پیشرفته، آموزش برای همه.
نوآوری
روش‌های خلاقانه برای یادگیری بهتر و سریع‌تر.
جامعه پویا
یک جامعه حمایت‌کننده از برنامه‌نویسان فارسی‌زبان.
بروزرسانی روزانه
هر روز محتوای جدید اضافه می‌شود.
دسترسی آزاد
همه محتوا رایگان و در دسترس همه است.
بلاگ

مطالب جدید

تازه‌ترین مطالب آموزشی و خبرهای مرتبط.

Rust 1.97.0 منتشر شد نوشته شده توسط عرفان دهقانی

Rust 1.97.0 منتشر شد

۹ جولای ۲۰۲۶، تیم Rust نسخه‌ی ۱.۹۷.۰ رو منتشر کرد. این نسخه تغییرات زبانی بزرگی نداره، ولی سه چیزی که اضافه شده از اون دسته چیزهاییه که وقتی باهاشون کار می‌کنی، خوشحال می‌شی که هستن.

برای آپدیت:

rustup update stable

Symbol mangling v0 حالا پیش‌فرضه

این یکی یه تغییر زیرپوستیه که بیشتر وقت‌ها متوجهش نمی‌شی — تا وقتی که یه stack trace می‌گیری و یهو می‌بینی اسم functionها خوانا شدن.

وقتی Rust کد رو کامپایل می‌کنه، اسم هر item رو mangle می‌کنه تا با اسم‌های مشابه در crate‌های دیگه تداخل نداشته باشه. روش قدیمی از Itanium ABI که C++ هم ازش استفاده می‌کنه الهام گرفته بود — ولی مشکل داشت: generic parameterها فقط پشت یه hash پنهان می‌شدن، و بخش‌هایی از mangling از استاندارد Itanium منحرف شده بودن که همین باعث می‌شد demangler‌های خارجی درست کار نکنن.

روش جدید (v0) از Rust 1.59 به‌عنوان opt-in موجود بود، از نوامبر ۲۰۲۵ روی nightly پیش‌فرض شده بود، و حالا توی ۱.۹۷ به stable رسیده. نتیجه‌ی عملی: وقتی یه panic یا stack trace می‌بینی، اسم functionها همراه generic parameterهاشون نشون داده می‌شن، نه یه رشته‌ی hash‌شده‌ی نامفهوم.

روش قدیمی الان فقط روی nightly در دسترسه و برنامه اینه که در آینده کاملاً حذف بشه.

Cargo حالا warning‌ها رو مدیریت می‌کنه

تا قبل از این، رایج‌ترین راه برای deny کردن warning‌ها در CI این بود:

RUSTFLAGS=-Dwarnings cargo build

مشکل این روش اینه که -Dwarnings رو به هر invocation از rustc پاس می‌ده، و این build cache رو invalidate می‌کنه. یعنی هر بار که توی CI این flag رو داری، از کش استفاده نمی‌شه و همه چیز از صفر compile می‌شه.

از ۱.۹۷، Cargo خودش کنترل می‌کنه که warning‌ها چطور با موفقیت build تعامل داشته باشن. یه env var جدید اضافه شده:

# در CI: deny کردن warning‌ها
CARGO_BUILD_WARNINGS=deny cargo build

# موقع کار: خاموش کردن موقت warning‌ها
CARGO_BUILD_WARNINGS=allow cargo check

# حالت پیش‌فرض: نمایش بدون fail کردن
CARGO_BUILD_WARNINGS=warn cargo build

مزیت مهم اینه که این متغیر build cache رو invalidate نمی‌کنه. یعنی می‌تونی توی CI deny داشته باشی و همچنان از کش استفاده کنی. می‌شه با --keep-going هم ترکیبش کرد تا به‌جای توقف روی اولین خطا، همه‌ی خطاها و warning‌ها یکجا جمع بشن.

خروجی linker دیگه پنهان نمی‌شه

rustc وقتی کامپایل می‌کنه، یه linker رو از طرف کاربر صدا می‌زنه. تا الان اگه link موفق می‌شد، هر پیامی که linker داشت پنهان می‌شد. این رفتار گاهی مشکل‌ساز بود چون warning‌های واقعی linker — مثل deprecation warning برای یه optimization flag قدیمی — اصلاً دیده نمی‌شدن.

از ۱.۹۷، پیام‌های linker به‌صورت پیش‌فرض نمایش داده می‌شن:

warning: linker stderr: ignoring deprecated linker optimization setting '1'
  |
  = note: `#[warn(linker_messages)]` on by default

تیم Rust پیام‌هایی که false positive شناخته‌شده هستن رو فیلتر کرده تا نویز اضافه نداشته باشی. اگه یه پیام می‌بینی که فکر می‌کنی false positive هست، می‌تونی توی Cargo.toml آن را خاموش کنی:

[lints.rust]
linker_messages = "allow"

یه نکته مهم: این lint عمداً از گروه warnings جدا نگه داشته شده. یعنی CARGO_BUILD_WARNINGS=deny روی linker_messages تاثیر نمی‌ذاره — چون خروجی linker از پلتفرمی به پلتفرم دیگه فرق می‌کنه و نمی‌شه به‌طور قطعی همه‌شون رو deny کرد.

APIهای جدید stable شده

چند API مرتبط با bit manipulation اضافه شده که برای کدهای سطح‌پایین کاربردیه:

let x: u32 = 0b1010_1100;

// جدا کردن بیت بالایی
x.isolate_highest_one(); // => 0b1000_0000

// جدا کردن بیت پایینی
x.isolate_lowest_one(); // => 0b0000_0100

// مقدار بیت بالایی
x.highest_one(); // => 0b1000_0000

// مقدار بیت پایینی
x.lowest_one(); // => 0b0000_0100

// تعداد bitهای لازم برای نمایش مقدار
x.bit_width(); // => 8

همه‌ی این methodها روی NonZero<T> هم در دسترسن. char::is_control هم حالا توی context‌های const کار می‌کنه.

یه تغییر کوچیک برای کاربران WebAssembly

اگه با WebAssembly کار می‌کنی، یه breaking change هست که از نسخه‌ی ۱.۹۶ شروع شده: Rust دیگه به‌طور پیش‌فرض --allow-undefined به linker پاس نمی‌ده. یعنی symbolهای undefined الان linker error هستن، نه WebAssembly import‌های ضمنی. اگه intentional بود، باید صریح تعریفش کنی:

#[link(wasm_import_module = "env")]
unsafe extern "C" {
    fn my_extern_function();
}

این release از نظر حجم تغییرات زبانی یه نسخه‌ی آروم بود، ولی هر سه‌ی این تغییرها از اون دسته چیزهاییه که بعد از یه مدت کار کردن باهاشون، نفهمیدی چطور قبلاً بدونشون کار می‌کردی.

Muse Spark 1.1: متا وارد بازار API پولی شد نوشته شده توسط عرفان دهقانی

Muse Spark 1.1: متا وارد بازار API پولی شد

۹ جولای ۲۰۲۶، متا همزمان دو کار کرد: یه مدل جدید منتشر کرد و برای اولین‌بار پول گرفت. این دومی شاید مهم‌تر از اولی باشه.

متا سال‌ها روی open-source بود — Llama، Llama 2، Llama 3 — و هویتش رو روی این گذاشته بود که «ما مدل‌ها رو رایگان می‌دیم». Muse Spark 1.1 اولین مدل frontier متاست که پشت یه paid API قرار گرفته. این یعنی متا دیگه فقط یه تامین‌کننده‌ی مدل open-source نیست — داره مستقیم وارد همون بازاری می‌شه که Anthropic و OpenAI ازش پول در می‌آرن.

مدل چیه

Muse Spark 1.1 نسخه‌ی ارتقاءیافته‌ی Muse Spark اصلیه که اپریل ۲۰۲۶ منتشر شد — اولین مدل از Meta Superintelligence Labs، واحدی که Alexandr Wang (موسس Scale AI) رهبریش رو بر عهده داره. این مدل multimodal و reasoning-based هست و برای کارهای agentic طراحی شده: متن، تصویر، و ویدیو رو می‌فهمه، از ابزارها و سرویس‌های خارجی استفاده می‌کنه، کدنویسی و دیباگ می‌کنه، و می‌تونه وظایف چندمرحله‌ای رو با دخالت کمتر انسان انجام بده.

context window یه میلیون توکن داره، که برای کارهای agentic طولانی‌مدت عدد مهمیه. یه ویژگی هم که متا روش تاکید کرده اینه که مدل می‌تونه به‌جای اینکه sequential کار کنه، parallel subagent بزنه — یعنی چند بخش از یه task رو همزمان پیش ببره.

کجا قوی‌ترین، کجا عقب‌تر

متا روی benchmark‌هایی مثل MCP Atlas، JobBench، Humanity's Last Exam، و FinanceBench عملکرد خوبی نشون داده. MCP Atlas مخصوصاً مهمه چون tool-call success رو روی task typeهای مختلف می‌سنجه — و این دقیقاً همون چیزیه که برای ساختن agent واقعی اهمیت داره.

ولی متا خودش هم صادق بوده: روی benchmark‌های خالص کدنویسی و reasoning، Opus 4.8 از آنتروپیک و GPT-5.5 از OpenAI هنوز جلوترن. و Mythos 5 و Fable 5 آنتروپیک و GPT-5.6 سول از OpenAI هم کلاً در یه لیگ دیگه‌ان. Muse Spark 1.1 رو نه باید با بهترین مدل‌های موجود مقایسه کنی، نه باید دست کم بگیریش.

قیمت‌گذاری

هر یک‌میلیون توکن ورودی ۱.۲۵ دلار، خروجی ۴.۲۵ دلار. این عدد رو بذار کنار بقیه:

توکن ورودی‌های Claude Haiku 4.5 و GPT-5.6 Luna از Muse Spark ارزون‌ترن، ولی Sonnet 4.6 آنتروپیک و مدل‌های میانه‌ی OpenAI گرون‌ترن. یعنی Muse Spark 1.1 توی طیف mid-tier قیمتی قرار می‌گیره — نه ارزون‌ترین، نه گرون‌ترین. برای کسی که می‌خواد یه مدل agentic با context window بزرگ و قیمت معقول داشته باشه، جای جالبیه.

توسعه‌دهنده‌هایی که ثبت‌نام می‌کنن ۲۰ دلار اعتبار رایگان می‌گیرن.

نکته‌ای که توسعه‌دهنده‌ها باید بدونن

Meta Model API هم با OpenAI SDK سازگاره هم با Anthropic Messages format. یعنی اگه الان روی یکی از این دوتا کار می‌کنی، اشتکال‌پذیری به Muse Spark نیاز به rewrite نداره — فقط base URL رو به api.meta.ai/v1 تغییر بده، key بده، و اسم مدل رو muse-spark-1.1 بذار.

این یه تصمیم توزیع‌گر هوشمندانه‌ست. یعنی تیم‌ها می‌تونن Muse Spark رو A/B کنن با مدل فعلیشون بدون اینکه stack رو از نو بسازن.

این هفته برای متا

Muse Spark 1.1 تنها چیزی نبود که این هفته از متا اومد. دو روز قبلش Muse Image و Muse Video هم منتشر شدن — اولین مدل‌های تولید تصویر و ویدیوی Superintelligence Labs. ولی Muse Image یه جنجال هم به‌همراه آورد: اجازه داد کاربرا روی عکس‌های public اینستاگرامی که دیگران گذاشتن افکت AI اعمال کنن، بدون اینکه از صاحب عکس اجازه گرفته بشه. این تصمیم با اعتراض زیادی روبه‌رو شد.

وضعیت دسترسی

مدل الان توی «Thinking mode» در اپ Meta AI و سایت meta.ai در دسترسه — بدون نیاز به API. برای توسعه‌دهنده‌ها، Meta Model API به‌صورت public preview فعلاً فقط برای آمریکاییاست.

متا گفته این مدل در آینده جای Llama رو توی WhatsApp، Instagram، Facebook، و عینک‌های هوشمند متا هم می‌گیره. مارک زاکربرگ هم برای اولین‌بار از جولای ۲۰۲۳ روی X پست گذاشت که این مدل «strong agentic and coding model at a very low price» هست. سه سال سکوت روی یه پلتفرم برای اعلام یه مدل AI — این یه نشانه از اینه که داخل متا چقدر به این لانچ اهمیت می‌دن.

رقابت AI این هفته به‌طرز جالبی شلوغ بود. بازار داره به یه سمتی می‌ره که قیمت‌ها پایین‌تر، context windowها بزرگ‌تر، و تمرکز بیشتر روی کار agentic هست. Muse Spark 1.1 دقیقاً وسط همین جریانه.

TypeScript 7 Stable منتشر شد و حدودا ۱۰ برابر سریع تره نوشته شده توسط عرفان دهقانی

TypeScript 7 Stable منتشر شد و حدودا ۱۰ برابر سریع تره

۸ جولای ۲۰۲۶، مایکروسافت نسخه‌ی stable از TypeScript 7 رو منتشر کرد. بعد از حدود یه سال preview و beta و RC، حالا دیگه آزمایشی نیست.

اگه مقاله‌ی قبلی ما درباره‌ی RC رو خونده باشی، می‌دونی ماجرا از کجا شروع شد: مایکروسافت کامپایلر TypeScript رو که از ابتدا با JavaScript نوشته شده بود، با Go بازنویسی کرد. ولی «بازنویسی» دقیقاً کلمه‌ی درستی نیست — این یه port بود. ساختار کد، الگوریتم‌ها، و data structureها حفظ شدن، فقط زبان پیاده‌سازی عوض شد. نتیجه اینه که semantics تایپ‌چک دقیقاً همونه، ولی سرعتش حالا چیز دیگه‌ایه.

اعداد واقعی روی پروژه‌های واقعی

مایکروسافت همراه با اعلام stable، benchmark روی چند codebase واقعی منتشر کرده. روی VS Code با ۲.۳ میلیون خط کد، تایپ‌چک از ۱۲۵ ثانیه به ۱۰.۶ ثانیه رسیده — نزدیک ۱۲ برابر. روی Sentry با ۱.۹ میلیون خط، ۱۵.۷ ثانیه. روی Bluesky با ۶۲۸ هزار خط، ۲.۸ ثانیه. روی Playwright با ۵۲۸ هزار خط، ۱.۴۷ ثانیه.

عدد کلی که مایکروسافت می‌گه «اغلب بین ۸ تا ۱۲ برابر» هست — نه ۱۰ برابر ثابت. این بستگی داره به اندازه‌ی پروژه و ساختار dependency graph.

دلیل این سرعت دو چیز بود: اول، Go binary به‌جای JavaScript interpreted اجرا می‌شه. دوم، کامپایلر جدید می‌تونه از shared memory parallelism استفاده کنه. به‌صورت پیش‌فرض با ۴ worker تایپ‌چک می‌کنه — می‌تونی با flag --checkers این عدد رو تنظیم کنی. worker بیشتر یعنی سریع‌تر، ولی رم بیشتر هم می‌خواد.

برای چی این‌قدر طول کشید؟

وقتی مارس ۲۰۲۵ Anders Hejlsberg این پروژه رو اعلام کرد، خیلی‌ها انتظار نداشتن که اینقدر زود stable بشه. در واقع beta اپریل ۲۰۲۶ اومد، RC ژوئن ۲۰۲۶، و stable جولای ۲۰۲۶ — تقریباً ۱۵ ماه از اعلام تا stable. دلیل این سرعت نسبی اینه که از صفر طراحی نشد؛ port بود نه rewrite.

مایکروسافت بیش از یه سال با تیم‌های داخلی و شرکت‌هایی مثل Bloomberg، Canva، Figma، Google، Notion، Slack، Vercel و VoidZero روی preview buildها کار کرد. نتیجه اینه که از روز اول stable، این مدل‌ها روی codebaseهای میلیون‌خطی تایید شده.

نصب

npm install -D typescript@latest

همین. دیگه خبری از @typescript/native-preview یا tsgo نیست — اون package برای دوران beta بود. از این به بعد همه چیز از همون typescript package معمولی میاد و با همون tsc اجرا می‌شه.

برای چک کردن نسخه:

npx tsc --version  # باید TypeScript 7.x.x باشه

چی ممکنه بشکنه

TypeScript 7 با TypeScript 6 از نظر تایپ‌چک compatible هست — یعنی کدی که با ۶ compile می‌شد باید با ۷ هم compile بشه. با این حال، چند تغییر هست که باید بدانی:

--target es5 و format‌های output مثل AMD، UMD و SystemJS حذف شدن. moduleResolution: "node10" (همون قدیمی‌ترها که node می‌نوشتن) هم نیست. rootDir حالا به‌صورت پیش‌فرض ./ هست نه root پروژه، و types به‌صورت پیش‌فرض آرایه‌ی خالیه.

اگه مستقیم از TypeScript 5 یا قدیمی‌تر upgrade می‌کنی — نه ۶ — احتمال مشکل بیشتره چون این deprecationها توی ۶ warning بودن و حالا توی ۷ hard error شدن. توصیه اینه که اگه روی ۵ هستی، اول به ۶ بری و بعد به ۷.

یه چیز مهم که هنوز نیست

API برنامه‌نویسی TypeScript — همونی که ابزارهایی مثل typescript-eslint، ts-morph، و custom transformerها ازش استفاده می‌کنن — توی ۷.۰ پایدار نیست. مایکروسافت گفته این API توی نسخه‌ی ۷.۱ که چند ماه دیگه میاد آماده می‌شه.

یعنی اگه workflow‌ات به این ابزارها وابسته‌ست، فعلاً باید یه سری چیزها رو pinned روی TypeScript 6 نگه داری:

npm install -D @typescript/typescript6   # aliased package برای linting

مایکروسافت یه compatibility package برای این کار منتشر کرده تا بتونی هم ۶ هم ۷ رو side-by-side داشته باشی.

editor

برای VS Code، TypeScript Native Preview extension که قبلاً جداگانه نصب می‌کردی دیگه لازم نیست — همون typescript package که توی پروژه نصبه، editor هم ازش استفاده می‌کنه. فقط یه بار VS Code رو restart کن.

اگه روی editor دیگه‌ای کار می‌کنی (Neovim، Zed، Cursor)، language server protocol یکیه — هر clientی که از tsserver استفاده می‌کنه خودش سریع‌تر می‌شه بدون اینکه config خاصی بخواد.

نظر شخصی

این نوع تغییرات نادره. معمولاً «مهم‌ترین release در سال‌های اخیر» یه عبارت overused هست، ولی اینجا واقعاً صدق می‌کنه — نه به‌خاطر یه feature جدید، بلکه به‌خاطر اینکه یه چیزی که همه باهاش کنار اومده بودن (کامپایلر کند) یهو یه مقیاس کامل فرق کرده. اگه روی پروژه‌ی بزرگی کار می‌کنی که تایپ‌چک CI بیشتر از یه دقیقه طول می‌کشه، آپدیت کردن به ۷ احتمالاً صرفه‌جویانه‌ترین کاریه که می‌تونی این هفته انجام بدی.

این موضوع واقعا من رو به شخصه آزار میداد. من سیستمم بد  نیست ولی تاپ ناچم نیست و خب لود شدن تایپ اسکریپت برام انقدر کند بود که واقعا ازاردهنده بود. هنوز بررسیش نکردم ولی خب I have a lot of hope

Next.js 16.3 Turbopack: وقتی dev server دیگه ۲۱ گیگ رم نمی‌خوره نوشته شده توسط عرفان دهقانی

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 با هم دیگه دعوا نمی‌کنن سر رم.