۸ جولای ۲۰۲۶، مایکروسافت نسخه‌ی 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 بزرگ کار کردی و یه نقطه‌ای رسیدی که 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 با هم دیگه دعوا نمی‌کنن سر رم.

اگه یه پروژه‌ی TypeScript بزرگ داری و تایپ‌چک هر بار چند دقیقه طول می‌کشه، این خبر برات جالبه: مایکروسافت ۱۸ ژوئن ۲۰۲۶ نسخه‌ی Release Candidate از TypeScript 7 رو منتشر کرد. نسخه‌ی stable هم قراره تا اواخر جولای ۲۰۲۶ بیاد.

چیزی که این نسخه رو از همه‌ی نسخه‌های قبلی متمایز می‌کنه اینه که کامپایلر دیگه با JavaScript نوشته نشده — حالا با Go نوشته شده. این پروژه از مارس ۲۰۲۵ با اعلام Anders Hejlsberg شروع شد، حدود پانزده ماه در فضای عمومی توسعه پیدا کرد، و حالا به مرحله‌ای رسیده که مایکروسافت می‌گه آماده‌ی استفاده‌ی روزانه است.

چرا Go؟

سوال منطقیه. TypeScript خودش یه زبان strongly-typed هست، چرا کامپایلرش رو با Go بنویسن نه Rust یا حتی TypeScript خودش؟

دلیل اصلی اینه که Go برای این نوع workload — یعنی parse کردن فایل‌های موازی، مدیریت حافظه‌ی مشترک، و پیاده‌سازی یه language service همزمان — tooling و runtime بهتری داره. Rust هم می‌تونست کار کنه، ولی تیم تصمیم گرفت با Go برگشت سریع‌تری داشته باشه.

نکته‌ی مهم‌تر اینه که این یه port هست نه یه rewrite از صفر. تیم TypeScript ساختار کد، الگوریتم‌ها، و data structureهای کامپایلر رو حفظ کرده — فقط زبان پیاده‌سازی عوض شده. این یعنی semantics تایپ‌چک دقیقاً همونه. در آزمون‌هایی که مایکروسافت انجام داده، از حدود ۲۰ هزار تست‌کیس کامپایلر، TypeScript 7 در همه جز ۷۴ مورد دقیقاً همون خطاهای TypeScript 6 رو برمی‌گردونه.

چقدر سریع‌تره؟

عدد رسمی که مایکروسافت داده «اغلب حدود ۱۰ برابر سریع‌تر از TypeScript 6» هست. این یه میانگین روی پروژه‌های مختلفه، نه یه عدد ثابت. روی codebase خود VS Code که حدود ۱.۵ میلیون خط هست، تایپ‌چک از ۷۷.۸ ثانیه به ۷.۵ ثانیه رسیده — حدود ۱۰.۴ برابر. زمان لود پروژه توی editor هم از ۹.۶ ثانیه به ۱.۲ ثانیه رسیده، و مصرف حافظه هم تقریباً نصف شده.

دو چیز این سرعت رو ممکن کرده: اول، Go binary به‌جای کد JavaScript interpreted اجرا می‌شه. دوم، مایکروسافت ساختار language service رو بازطراحی کرده تا از shared-memory parallelism استفاده کنه — چیزی که با runtime تک‌thread قبلی اصلاً ممکن نبود.

چی تغییر کرده که ممکنه کدت رو بشکنه

TypeScript 7 یه سری breaking change داره که اکثرشون از نسخه‌ی ۶ که «bridge release» بود، deprecated شده بودن:

پشتیبانی از --target es5 حذف شده. اگه هنوز برای مرورگرهای قدیمی build می‌گیری، باید از ابزارهای دیگه‌ای مثل Babel استفاده کنی. فرمت‌های output مثل AMD، UMD و SystemJS هم حذف شدن. moduleResolution: "node10" (که قبلاً به اسم node هم شناخته می‌شد) حذف شده و باید به bundler یا node16 تغییر پیدا کنه. --baseUrl و --paths هم رفتار قبلی‌شون رو ندارن و باید با paths توی tsconfig.json جایگزین بشن.

یه تغییر مهم دیگه اینه که rootDir حالا به‌صورت پیش‌فرض به ./src اشاره می‌کنه نه root پروژه.

مایکروسافت می‌گه ۹۵ درصد پروژه‌های TypeScript 6 بدون تغییر compile می‌شن. ولی اون ۵ درصد رو باید جدی بگیری — خصوصاً اگه پروژه‌ی قدیمیه یا config پیچیده داره.

API programmatic هنوز آماده نیست

یه محدودیت مهم که باید بدانی: API برنامه‌نویسی TypeScript — همونی که ابزارهایی مثل ts-jest، ts-node، و eslint-plugin-typescript ازش استفاده می‌کنن — هنوز در TypeScript 7 پایدار نیست. مایکروسافت گفته این API توی نسخه‌ی ۷.۱ که چند ماه بعد از ۷.۰ stable میاد آماده می‌شه.

یعنی اگه از این ابزارها استفاده می‌کنی، باید صبر کنی یا با احتیاط تست کنی.

چطور الان امتحانش کنی

npm install -D typescript@rc

همین. بعد از این:

npx tsc --version   # باید v7.0.0-rc باشه
npx tsc --noEmit    # تایپ‌چک کل پروژه

tsc داخل typescript@rc همون باینری Go هست. اسم tsgo که توی preview‌های ۲۰۲۵ استفاده می‌شد، حالا فقط برای nightly channel مانده.

برای rollback هم typescript@6 رو کنار داشته باش:

npm install -D typescript@6   # نسخه‌ی قبلی

آیا الان باید به پروداکشن ببریش؟

RC هست، نه stable. مایکروسافت می‌گه «highly stable» هست و بیش از یه سال pre-release testing داشته، ولی هنوز GA نشده.

برای سرویس‌های داخلی و pipeline های CI که فقط type-check می‌کنن و emit نمی‌کنن، همین الان می‌ارزه امتحانش کنی. اگه از API برنامه‌نویسی استفاده می‌کنی یا workflow پیچیده‌ای داری، صبر کن stable بیاد — که طبق برنامه اواخر جولای ۲۰۲۶ هست.

این بزرگ‌ترین تغییر توی TypeScript از همون اول بود. نه یه feature جدید، نه یه syntax تازه — یه تغییر بنیادی توی اینکه کامپایلر اصلاً چطور کار می‌کنه. و از اون نوع تغییراتیه که اکثر توسعه‌دهنده‌ها بدون اینکه بدونن چی عوض شده، فقط حس می‌کنن IDE یهو خیلی سریع‌تر شده.

یه چیز جالب داره توی فضای توسعه نرم‌افزار اتفاق می‌افته: یه بخش قابل‌توجه از کدی که توی Next.js نوشته می‌شه دیگه توسط انسان‌ها تایپ نمی‌شه. Claude Code، Cursor، Codex — این‌ها دارن به ابزارهای اصلی خیلی از تیم‌ها تبدیل می‌شن. تیم Next.js یه سوال جالب پرسیده: اگه فریم‌ورک می‌دونست که اکثر کدش رو یه agent می‌نویسه، چی فرق می‌کرد؟

۲۶ ژوئن ۲۰۲۶، Next.js 16.3 یه پست مجزا فقط برای بهبودهای AI-محور منتشر کرد — چیزی که قبلاً سابقه نداشت. این مقاله رو مرور می‌کنه.

AGENTS.md: agent بخونه، نه training data رو

توی نسخه‌ی ۱۶.۲، Next.js شروع کرد به bundled کردن مستنداتش داخل پروژه. ایده ساده بود: agent‌ها اغلب از training data خودشون استفاده می‌کنن، که ممکنه چند نسخه عقب‌تر باشه. اگه داک‌های نسخه‌ی فعلی رو داخل node_modules بگذاری و از طریق AGENTS.md بهش اشاره کنی، agent مجبور می‌شه نسخه‌ی درست رو بخونه.

توی ۱۶.۳، next dev به‌طور خودکار این pointer رو می‌نویسه و به‌روز نگه می‌داره. پروژه‌های قدیمی‌تر می‌تونن با یه codemod یه‌بار این کار رو بکنن:

npx @next/codemod@canary agents-md

بلوکی که next dev به AGENTS.md اضافه می‌کنه صریحه:

<!-- BEGIN:nextjs-agent-rules -->
# This is NOT the Next.js you know
This version has breaking changes — APIs, conventions, and file structure
may all differ from your training data. Read the relevant guide in
`node_modules/next/dist/docs/` before writing any code.
<!-- END:nextjs-agent-rules -->

این بلوک فقط وقتی next dev یه AI coding agent رو توی environment تشخیص بده نوشته می‌شه، و هر چیزی بیرون از marker‌ها دست‌نخورده می‌مونه.

Skills: وقتی داک کافی نیست

Skills برای workflow‌های چندمرحله‌ای‌اند — جایی که داک‌ها تنها نمی‌تونن agent رو از اول تا آخر هدایت کنن. سه Skill جدید اضافه شده:

next-dev-loop: به agent دسترسی به dev loop کامل می‌ده — مرورگر، console، network، و درخت React. بعد از هر ویرایش می‌تونه ببینه صفحه هنوز کار می‌کنه یا نه.

npx skills add vercel/next.js --skill next-dev-loop

next-cache-components-adoption: Cache Components رو توی پروژه فعال می‌کنه و یه feature در یه زمان پیش می‌ره. دو mode داره: incremental که یه PR مکانیکی می‌سازه و بقیه رو می‌ذاره برای بعد، و direct که همه‌ی route‌ها رو یه‌جا روی یه branch تغییر می‌ده.

next-cache-components-optimizer: یه route رو برای instant navigation بهینه می‌کنه با یه حلقه‌ی observe-fix-iterate روی static shell. قبل و بعد از هر تغییر screenshot می‌گیره؛ اگه تصاویر یکسان باشن، تغییر rollback می‌شه.

Agent Browser با React introspection

next-browser که توی ۱۶.۲ اضافه شده بود حالا merge شده توی agent-browser — یه CLI همه‌منظوره که فراتر از Next.js هم کار می‌کنه.

نسخه‌ی ۰.۲۷ یه چیز مهم اضافه کرده: React DevTools introspection. Agent‌ها الان می‌تونن درخت کامپوننت رو لیست کنن، یه کامپوننت خاص رو inspect کنن، re-renderها رو profile کنن، و ببینن چی یه render رو نگه داشته.

Actionable errors: خطا با دستورالعمل

وقتی Cache Components فعاله، یه await روی سرور یه انتخابه. Instant Insights این انتخاب رو به‌عنوان یه error با سه fix مشخص نشون می‌ده: Stream با <Suspense>، Cache با "use cache"، یا Block با export const instant = false.

اما مهم‌تر از خود error، یه دکمه‌ی «Copy prompt» اضافه شده. این دکمه fix انتخاب‌شده رو بسته‌بندی می‌کنه توی یه پرامپت آماده برای agent: شناسایی کد مشکل‌دار، خوندن داک مربوط، اعمال pattern، و تایید نتیجه توی مرورگر از طریق next-dev-loop.

همین fix menu توی terminal هم هست. next build و next dev هر دو خطاها رو با گزینه‌های labeled و لینک به بخش مربوطه از داک‌ها output می‌کنن — یعنی agent‌هایی که dev overlay ندارن و فقط terminal رو می‌خونن همون اطلاعات رو می‌گیرن.

هر error یه صفحه‌ی مجزا روی nextjs.org/docs/messages داره که برای خوندن توسط agent‌ها نوشته شده. هر صفحه همون ساختار رو داره: Patterns، Trade-offs، و Gotchas — یه چیزی که agent‌ها توی اولین تلاش احتمالاً بهش توجه نمی‌کنن.

MCP server: کوچیک‌تر و متمرکزتر

MCP server قبلاً یه knowledge base داخلی داشت. با اینکه bundled docs الان همون کار رو می‌کنه، اون ابزارها حذف شدن. در عوض، دو ابزار جدید اضافه شده: get_compilation_issues برای کل پروژه، و compile_route برای یه route خاص. agent‌ها اغلب next build می‌زدن فقط برای چک کردن compilation — این ابزارها همون سوال رو از dev server در حال اجرا جواب می‌دن، خیلی سریع‌تر.

Docs as Markdown

یه چیز ساده ولی کاربردی: به هر URL از داک‌های Next.js یه .md اضافه کن تا نسخه‌ی Markdown صفحه رو بگیری. همین برای صفحه‌های error هم کار می‌کنه.

ایندکس کامل روی /docs/llms.txt هست، و /docs/llms-full.txt همه‌ی صفحات رو توی یه فایل bundle می‌کنه — طبق convention استاندارد llms.txt.

یه قدم به سمت agent-first development

اگه بخوای خیلی ساده بگی چی اضافه شده: Next.js داره سعی می‌کنه agent‌ها رو مثل یه نوع developer جدید در نظر بگیره — با نیازهای متفاوت. Agent به داک‌های به‌روز نیاز داره نه training data قدیمی، به خطاهای actionable نیاز داره نه فقط error message، و به یه feedback loop نیاز داره که بتونه بعد از هر تغییر runtime رو چک کنه.

فعلاً هنوز preview هست. اگه می‌خوای همین الان امتحان کنی:

npm install next@preview

و بعد ببین کدوم بخش از workflow توسعه‌ات واقعاً بهتر می‌شه — یا نمی‌شه.