خبر

مباحث پیشرفته تا Foreign Function and Memory

چرا این منبع برای توسعه‌دهندگان ایرانی اهمیت دارد؟

مزایا و محدودیت‌های این مستندات

• پوشش کامل و پیوسته از مفاهیم مقدماتی تا مباحث پیشرفته‌ای مانند FFM.
• استفاده از زبان ساده، روان و دور از پیچیدگی‌های غیرضروری و آکادمیک.
• دسترسی آسان، آنلاین و رایگان در پلتفرم Codoloper.
• به‌روز بودن محتوا و انعکاس ویژگی‌های نسخه‌های جدید زبان جاوا.

• این مستندات بیشتر بر روی مفاهیم زبانی و APIهای استاندارد تمرکز دارد و برای یادگیری فریم‌ورک‌های خاص سازمانی مانند Spring Boot نیاز به منابع تکمیلی خواهید داشت.
• یادگیری برنامه‌نویسی نیازمند تمرین عملی است و این مستندات به تنهایی جایگزین نوشتن کد و انجام پروژه‌های واقعی نمی‌شود.

مقایسه با سایر منابع آموزشی

جمع‌بندی نهایی و نگاه شخصی

سوالات متداول

برای چک کردن نسخه: پایین هر صفحه‌ی admin وردپرس نسخه رو می‌بینی، یا از Dashboard → Updates برو.

چطور آپدیت کنی

از Dashboard → Updates برو و دکمه‌ی Update to 7.0.2 (یا نسخه‌ی مربوط به branch ات) رو بزن. وردپرس به‌خاطر شدت این آسیب‌پذیری، برای سایت‌های تحت تأثیر forced auto-update فعال کرده — ولی حتماً خودت هم تأیید کن که آپدیت انجام شده. auto-update همیشه کامل اجرا نمی‌شه.

بعد از آپدیت، یه بار به Dashboard → Updates برگرد و مطمئن شو نسخه‌ی جدید نصب شده.

اگه الان نمی‌تونی آپدیت کنی

اگه یه دلیل فنی هست که آپدیت فوری ممکن نیست (مثلاً نگران compatibility با پلاگین هستی)، دو اقدام موقت می‌تونی انجام بدی:

در WAF یا web server ات endpoint زیر رو block کن:

این دسترسی به batch endpoint رو می‌بنده و زنجیره‌ی RCE رو قطع می‌کنه. Cloudflare این rule رو از ساعت ۱۷:۰۳ UTC روز ۱۷ جولای برای همه‌ی کاربراش — حتی پلن رایگان — فعال کرده.

ولی این یه راه‌حل موقته، نه جایگزین آپدیت. با این آسیب‌پذیری‌ها، ساعت‌ها اهمیت دارن.

چرا این بار جدی‌تر از معموله

اکثر آسیب‌پذیری‌های وردپرس از پلاگین‌ها یا تم‌ها میان — نه از هسته‌ی خود وردپرس. این یکی متفاوته: مشکل توی core هست، یعنی هر نصب وردپرس تحت تأثیر روی هر سرور، با هر پلاگین و تنظیماتی، هدف بالقوه‌ایه. نیازی به هیچ تعاملی از طرف کاربر نیست، نیازی به guess کردن رمز نیست — یه درخواست HTTP ناشناس کافیه.

PoC عمومی بودن به این معنیه که حملات الان فعال‌ترن. اگه هنوز آپدیت نکردی، این رو جدی بگیر.

برای output هم:

چون immutable هست، ساختن چند variant از یه عکس تمیزه:

دو driver داره — GD و Imagick — و می‌تونی per-image هم انتخاب کنی:

یه نکته‌ی مهم: خود intervention/image به‌عنوان suggested dependency اضافه شده، نه required. یعنی باید خودت نصبش کنی:

ویژگی WithoutMiddleware

یه attribute جدید اضافه شده که counterpart ویژگی #[Middleware] هست. تا الان می‌تونستی روی کل controller یه middleware بذاری و برای بعضی method ها استثنا بدی. حالا این کار رو می‌تونی با attribute بکنی:

یه نکته‌ی ظریف: از ReflectionAttribute::IS_INSTANCEOF استفاده می‌کنه، یعنی subclass های اون middleware هم automatically exclude می‌شن.

پیشوند جداگانه برای Session در Redis

اگه هم SESSION_DRIVER و هم CACHE_STORE هر دو به Redis اشاره می‌کنن، تا الان session ها از همون prefix که برای cache تنظیم کردی استفاده می‌کردن. این debug کردن Redis keyspace رو مشکل می‌کرد.

حالا می‌تونی توی config/session.php یه prefix جداگانه بذاری:

cache store قبل از اعمال session prefix کلون می‌شه، پس این تغییر روی cache key ها تاثیر نمی‌ذاره.

incrementEachQuietly و decrementEachQuietly

Eloquent قبلاً incrementQuietly() و decrementQuietly() داشت که یه column رو بدون trigger کردن model event تغییر می‌دادن. این نسخه نسخه‌ی multi-column اینا رو اضافه کرده:

وقتی داری یه batch operation انجام می‌دی و نمی‌خوای event هایی مثل saved یا updated fire بشن، این دقیقاً چیزیه که می‌خوای.

Enum به‌عنوان کلید WithoutOverlapping

WithoutOverlapping middleware برای queue jobs الان مستقیم enum قبول می‌کنه:

قبلاً باید enum رو به string تبدیل می‌کردی. این تغییر backward compatible هست.

بقیه چیزهای کوچیک ولی مفید

چند چیز دیگه که کمتر headline می‌گیرن ولی در عمل کاربرد دارن:

make:migration حالا timestamp prefix هایی می‌سازه که collision-free و مرتب هستن — مشکل قدیمی که دو migration همزمان ساخته‌شده اسم تکراری می‌گرفتن.

#[SensitiveParameter] به parameter هایی که secret حمل می‌کنن اضافه شده، یعنی password ها و token ها دیگه توی stack trace نمایش داده نمی‌شن.

Storage::assertEmpty() اضافه شده که توی test ها مفیده.

Str::containsAll() دیگه برای آرایه‌ی خالی true برنمی‌گردونه — یه bug قدیمی که رفتار غیرمنطقی داشت.

Number::forHumans() دیگه برای عددهای خیلی کوچیک منفی، -0 برنمی‌گردونه.

upgrade کردن

تغییر breaking ای وجود نداره. اگه می‌خوای از Image facade استفاده کنی، فقط intervention/image رو نصب کن. بقیه‌ی تغییرات opt-in هستن یا bug fix.

این دستور لیست می‌ده بدون اینکه چیزی رو approve کنه. بعد از اینکه تیکرهایی که بهشون اعتماد داری رو approve کردی:

این approve به package.json commit می‌شه — یعنی می‌تونی توی PR review کنی و ببینی چه packageای اجرای script گرفته.

یه edge case مهم: npm rebuild هم subject to این block هست. اگه یه package توی allowlist نباشه، npm rebuild <package> بی‌سروصدا skip می‌کنه. راه‌حل:

تغییر دوم: Git dependency ها block می‌شن

اگه توی package.json ات چنین چیزی داری:

از npm 12 این کار نمی‌کنه مگه اینکه --allow-git استفاده کنی.

این تغییر از فوریه ۲۰۲۶ اعلام شده بود. دلیلش اینه که یه Git dependency می‌تونه یه .npmrc داخل خودش داشته باشه که مسیر اجرایی git رو override کنه — حتی وقتی --ignore-scripts هم گذاشته باشی. خیلی از تیم‌ها فکر می‌کردن --ignore-scripts محافظشون می‌کنه، ولی این attack vector کاملاً جدا بود.

اگه از Git dependency برای یه package داخلی استفاده می‌کنی، بهترین راه اینه که به یه registry مایگریت کنی — GitHub Packages، Nexus، یا Artifactory. اضافه کردن --allow-git به هر CI script، مشکل رو حل نمی‌کنه، فقط جابه‌جاش می‌کنه.

تغییر سوم: remote URL ها block می‌شن

مشابه Git، اگه package ای داری که از یه URL مستقیم نصب می‌شه:

از npm 12 بدون --allow-remote کار نمی‌کنه.

remote URL ها unverifiable ان — npm نمی‌تونه تضمین کنه که اون tarball دستکاری نشده. حل درست اینه که به یه registry بری که integrity check داره.

چطور الان آماده بشی

npm 11.16.0 آخرین نسخه‌ی stable از 11.x هست. اگه upgrade کنی، همه‌ی این blocking ها به‌صورت warning نشون داده می‌شن — نه error. یعنی می‌تونی قبل از اینکه npm 12 بیاد ببینی چی می‌شکنه:

بعد از اینکه لیست گرفتی، packageهایی رو که بهشون اعتماد داری approve کن و package.json رو commit کن. یه چیزی که نباید بکنی: همه رو با یه flag blanket approve کنی فقط برای اینکه warning‌ها ساکت بشن — این کل هدف تغییر رو از بین می‌بره.

کدوم پروژه‌ها بیشترین ریسک رو دارن

پروژه‌هایی که به احتمال بالا مشکل پیدا می‌کنن:

هر پروژه‌ای که native addon دارد — یعنی packageهایی مثل bcrypt، sharp، canvas، node-sass، یا هر چیزی که به C/C++ compile وابسته‌ست. این packageها برای کار کردن به script اجرا شدن نیاز دارن.

هر پروژه‌ای که Git dependency دارد — معمولاً برای fork های داخلی یا patched نسخه‌ها.

هر پروژه‌ای که از HTTPS tarball برای package های داخلی استفاده می‌کنه.

اگه از هیچ‌کدوم از اینا استفاده نمی‌کنی، احتمالاً npm 12 برات transparent باشه.

یه نکته درباره‌ی پکیج نویس‌ها

اگه خودت package نگهداری می‌کنی که native build داره، بهترین راه اینه که prebuilt binary بشیپ کنی — با ابزارهایی مثل prebuild، prebuildify، یا node-pre-gyp. packageای که install-time compilation نداره، نمی‌تونه از این attack vector استفاده بشه. این یه بهبود بلندمدت هست که ارزش وقت گذاشتن داره.

این بزرگ‌ترین تغییر امنیتی npm در شانزده سال گذشته‌ست. ولی فقط یه تغییر configuration نیست — یه تغییر مدل اعتماده. ده سال بود که هر npm install به‌معنای دادن حق اجرای کد دلخواه به همه‌ی چیزی بود که توی dependency tree ات بود. این پیش‌فرض داشت تغییر می‌کرد — فقط کمی طول کشید.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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/native-preview یا tsgo نیست — اون package برای دوران beta بود. از این به بعد همه چیز از همون typescript package معمولی میاد و با همون tsc اجرا می‌شه.

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

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

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 نگه داری:

مایکروسافت یه 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

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

برای 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 هست:

import.meta.glob

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

این به‌جای اینکه مجبور بشی اسم همه‌ی فایل‌ها رو hardcode کنی، هر فایلی که با pattern مطابقت داشته باشه رو import می‌کنه. نتیجه یه object هست که key‌هاش 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 با هم دیگه دعوا نمی‌کنن سر رم.

پشتیبانی از --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 میاد آماده می‌شه.

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

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

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

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

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

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

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

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

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

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

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

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

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 هست. اگه می‌خوای همین الان امتحان کنی:

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

یه مشکل دیگه هم وجود داشت که کمتر بهش توجه می‌شد: حتی اگه سرور سریع جواب بده، هنوز یه رفت‌وبرگشت شبکه بین client و سرور داری. Next.js قبلاً این مشکل رو با prefetch کردن لینک‌ها حل می‌کرد — برای هر لینکی که توی viewport بود، یه request جداگانه می‌زد. اگه یه sidebar با بیست لینک داشتی، بیست request. اگه به Network tab نگاه می‌کردی، یه طوفان از request‌ها می‌دیدی که به گفته‌ی خود تیم Next.js «مسخره به نظر می‌رسید».

توی ۱۶.۳ این رویکرد عوض شده: به جای prefetch کردن به‌ازای هر لینک، حالا یه shell به‌ازای هر route prefetch می‌شه. یعنی اگه بیست لینک داری که همه به /chat/[id] اشاره می‌کنن، فقط یه بار shell اون route دانلود می‌شه و کش می‌شه.

برای فعال کردن این رفتار:

البته اگه بخوای برای یه لینک خاص بیشتر از shell prefetch بشه — مثلاً header یه صفحه‌ی chat — می‌تونی با <Link prefetch={true}> opt-in کنی. توی اون حالت هم Next.js فقط تا جایی prefetch می‌کنه که synchronous یا 'use cache' باشه، نه کل route.

Instant Insights: slow navigation به‌عنوان error

چیزی که توی این آپدیت جالبه اینه که تیم Next.js تصمیم گرفته navigation‌های کند رو توی development mode به‌عنوان error نشون بده — نه warning، error. یه پنل جدید به اسم Instant Insights اضافه شده که به‌طور خودکار route‌هایی که instant نیستن رو پیدا می‌کنه و نشون می‌ده.

برای تست هم یه helper اضافه شده:

این یعنی می‌تونی توی CI هم چک کنی که navigation‌های instant بودنشون رو از دست ندادن.

یه Navigation Inspector هم اضافه شده که بهت اجازه می‌ده هر navigation رو «pause» کنی و ببینی shell چه شکلیه، قبل از اینکه داده‌های واقعی بیان.

چقدر واقعاً فرق می‌کنه

تیم Next.js گفته که این feature رو روی v0 — اپ داخلی Vercel — قبل از release استفاده کردن. نتیجه‌ای که منتشر کردن نشون می‌ده که navigation time از چند صد میلی‌ثانیه به نزدیک صفر رسیده برای اکثر route‌ها، بعد از اینکه کار روی route‌های کند رو تموم کردن.

البته این هنوز preview هست و یه سری محدودیت‌های شناخته‌شده هم وجود داره: بعضی route‌های blocking توی Instant Insights گزارش نمی‌شن، و tooling توی Safari مشکل داره. تیم گفتن که این‌ها قبل از stable release برطرف می‌شن.

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

بعدش cacheComponents: true رو به config اضافه کن و ببین کدوم route‌هات blocking هستن. اگه می‌خوای Partial Prefetching هم باشه، partialPrefetching: true رو هم اضافه کن.

یه دمو هم آماده کردن به اسم Next Beats — یه موزیک‌پلیر که روی Next.js 16.3 ساخته شده و سورسش هم روی GitHub هست — که می‌تونی ببینی navigation‌های instant در عمل چطور به نظر می‌رسن.

این مسیری که Next.js داره طی می‌کنه — گرفتن بهترین چیز SPA (navigation ایمدیت) بدون دادن مزایای server-centric — از نظر فنی جالبه. مشکل اصلی که همیشه بود این بود که مجبور بودی یا همه‌چیز رو client‌ side بکنی تا instant باشه، یا server‌ side بروی و سرعت navigation رو فدا کنی. حالا دیگه این trade‌off اجباری نیست.

این یعنی body خود query است — نه یه resource که باید ذخیره شود، نه یه command. سرور آن را پردازش می‌کند و نتیجه را برمی‌گرداند.

مقایسه‌ی سه متد از نظر پروتکل:

یه مکانیزم discovery هم اضافه شده: سرور می‌تواند با هدر جدید Accept-Query اعلام کند که چه media typeهایی را برای QUERY قبول می‌کند:

کش کردن چطور کار می‌کنه

QUERY قابل cache است، ولی کمی پیچیده‌تر از GET. cache key باید شامل محتوای request هم باشد، نه فقط URI. کش باید ابتدا کل body را بخواند و بعد تصمیم بگیرد آیا قبلاً این درخواست را دیده یا نه.

برای جلوگیری از miss‌های بی‌دلیل، cache‌ها اجازه دارند تفاوت‌های بی‌معنی را نرمالایز کنند — مثلاً ترتیب فیلدهای JSON. ولی اگه این نرمالایزیشن خیلی aggressive باشد، ممکن است cache جواب اشتباه را برگرداند. این edge case اصلی‌ایه که باید بهش توجه داشت.

چه کسی الان پشتیبانی می‌کنه

Node.Js از اوایل ۲۰۲۴ متد QUERY را به‌صورت native parse می‌کند، OpenAPI 3.2 می‌تواند آن را document کند، و Spring یه pull request باز دارد. وضعیت دقیق‌تر به این شکل است:

یه نکته مهم درباره مرورگر: QUERY یه CORS-safelisted method نیست، پس هر درخواست cross-origin یه preflight می‌زند. هزینه‌ی این OPTIONS اضافه را باید در نظر بگیری.

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

با curl و Node 22 همین الان می‌شود یه endpoint کاملاً کارکرد ساخت:

سمت سرور روی Node، req.method مقدار 'QUERY' را برمی‌گرداند:

از fetch هم همین‌طور کار می‌کند:

اگه روی Spring هستی، فعلاً باید صبر کنی یا یه servlet filter دستی بنویسی که درخواست‌های QUERY را پیش از Spring MVC بگیرد — ولی این یه راه‌حل موقتی است.

قبل پایانم این واژه هارو هم گفتم توضیح بدم که چی هستند:

Preflight Request:
درخواست اولیه‌ای از نوع OPTIONS که مرورگر قبل از ارسال درخواست اصلی در CORS می‌فرستد تا بررسی کند سرور اجازه دسترسی می‌دهد یا نه.

Safe Methods:
متدهایی که فقط برای خواندن داده استفاده می‌شوند و نباید هیچ تغییری در state سرور ایجاد کنند؛ مثل GET, HEAD, OPTIONS.

Idempotent Methods:
متدهایی که اگر چند بار پشت سر هم اجرا شوند، نتیجه نهایی یکسانی روی سرور دارند؛ مثل GET, PUT, DELETE.

پس باید الان ازش استفاده کنی؟

برای سرویس‌های داخلی روی Node، من همین الان استفاده می‌کنم. parser support وجود دارد، semantics استاندارد شده، و ترافیک داخلی نیازی به نگرانی از CDN یا بلوغ مرورگر ندارد.

برای API عمومی، عجله نکن. endpoint‌های POST فعلی‌ات را نگه دار و Accept-Query را اضافه کن تا client‌ها بدانند که QUERY هم پشتیبانی می‌شود. tooling داره می‌آید — OpenAPI 3.2 و ASP.NET 11 هر دو آن را می‌شناسند.

ده یازده سال از اولین draft تا استاندارد شدن طول کشید. HTTP سریع حرکت نمی‌کند، و دقیقاً به همین خاطر وقتی حرکت می‌کند ارزش توجه دارد.سرچ کردن با متد POST احتمالاً ظرف چند سال آینده به همان اندازه‌ای که الان X- header استفاده کردن به نظر قدیمی می‌رسد، legacy به نظر خواهد رسید.

Sonnet 5 واقعاً چقدر فرق دارد

ادعای اصلی آنتروپیک این است که Sonnet 5 به عملکرد Opus 4.8 نزدیک است، ولی با قیمت خیلی پایین‌تر. در API، نرخ تعارفی تا پایان اوت ۲۰۲۶ برای هر یک‌میلیون توکن ورودی دو دلار و خروجی ده دلار است، بعدش به سه و پانزده دلار می‌رسد. Opus 4.8 روی همین مقیاس پنج و بیست‌وپنج دلار است. از نظر اعداد، Sonnet 5 روی بنچمارک‌های BrowseComp و OSWorld-Verified خیلی به Opus 4.8 نزدیک‌تر از Sonnet 4.6 است.

تفاوت اصلی در agentic قابلیت‌هاست: برنامه‌ریزی چندمرحله‌ای، کنترل مرورگر و ترمینال، و چک‌کردن خودکار خروجی بدون این‌که لازم باشد توی پرامپت بگویی «جوابت رو بررسی کن». اینا قابلیت‌هایی بودند که قبلاً بیشتر مختص مدل‌های Opus بود. از نظر امنیت سایبری هم آنتروپیک می‌گوید Sonnet 5 هیچ‌وقت روی داده‌های تخصصی امنیتی آموزش ندیده، و در تست‌هایی که با موزیلا انجام شده، روی آسیب‌پذیری‌های شناخته‌شده‌ی فایرفاکس هیچ اکسپلویت کاملی تولید نکرده. به همین خاطر هم دولت آمریکا سراغش نیامده.

Fable 5 الان چه وضعیتی دارد

Fable 5 برگشته، ولی نه به همان شکلی که اول لانچ شده بود. دسترسی رایگان روی پلن‌های Pro و Max تموم شده — حالا به کردیت نیاز دارد. Anthropic گفته هدفش این است که در آینده Fable رو دوباره به‌عنوان بخشی از پلن‌های اشتراکی برگرداند، ولی زمان مشخصی نداده.

Mythos 5 هنوز محدود است. آنتروپیک دسترسی رو برای یه سری سازمان‌های آمریکایی تاییدشده برقرار کرده و داره فهرست Project Glasswing رو گسترش می‌دهد، ولی برای عموم در دسترس نیست و ظاهراً تا مدتی هم نخواهد بود.

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

یه نکته‌ی مهم که باید بدانی: Fable 5 فعلاً فقط از طریق API در دسترس است. اگه انتظار داری توی claude.ai یا Claude Code بروی و از منوی مدل‌ها انتخابش کنی، ناامید می‌شوی. آنتروپیک گفته که قصد دارد Fable رو دوباره به پلن‌های اشتراکی برگرداند، ولی نه الان و نه با زمانبندی مشخص.

یه نظر شخصی که شاید ارزش داشته باشه بشنوی

وسط همه‌ی این سروصداها، یه چیزی هست که کمتر کسی می‌گوید: Sonnet 4.6 هنوز خیلی خوبه. اگه کارت کد نوشتن، توضیح مفاهیم، خلاصه‌سازی، یا همین کارهای روزمره‌ی برنامه‌نویسیه، Sonnet 4.6 تقریباً همه‌شان رو راه می‌اندازد — و مهم‌تر از اون، رایگانه یا خیلی ارزون‌تر.

Sonnet 5 و Fable 5 قابلیت‌های واقعی دارند، مخصوصاً توی کارهای agentic طولانی‌مدت که مدل باید خودش چندین مرحله رو مدیریت کند. ولی برای اکثر کارهای روزانه‌ای که یه توسعه‌دهنده‌ی معمولی باهاشون طرفه، این فاصله‌ای که بین نسخه‌ها هست توی عمل خیلی کمتر از اعداد بنچمارک‌هاست. قبل از اینکه بروی کردیت بخری یا پلن رو ارتقا بدی، ارزش داره یه هفته با همان Sonnet 4.6 کار کنی و ببینی کجا واقعاً به دیوار می‌خوری — اگه اصلاً بخوری.

نکته‌ی فنی‌تر این‌جاست: OpenAI می‌گوید Sol از آستانه‌ی «بحرانی سایبری» تعریف‌شده در Preparedness Framework خودشان رد نشده. در آزمایش‌هایی روی Chromium و Firefox، مدل توانسته باگ و قطعات پایه‌ی یک exploit را پیدا کند، اما نتوانسته به‌طور خودکار یک زنجیره‌ی کامل و قابل‌اجرا بسازد. با این حال، خودشان هم تاکید کرده‌اند که هیچ بنچمارکی نمی‌تواند همه‌ی روش‌های استفاده‌ی واقعی را پیش‌بینی کند؛ برای همین کنار قابلیت بالاتر، سیستم ایمنی چندلایه هم گذاشته‌اند: محدودیت‌های آموزش‌دیده در خود مدل، کلاسیفایرهای بررسی لحظه‌ای خروجی، و بازبینی در سطح حساب کاربری برای رفتارهای مشکوک تکرارشونده.

قیمت و زمان‌بندی

برخلاف رفتار همیشگی OpenAI که مدل جدید را معمولاً مستقیم برای همه باز می‌کند، این‌بار فقط از طریق API و Codex، و فقط برای همان گروه محدود تایید‌شده در دسترس است. خودشان گفته‌اند قصد دارند به‌زودی آن را برای کاربران ChatGPT، Codex و API به‌طور عمومی منتشر کنند.

قیمت‌گذاری هم بر اساس هر یک‌میلیون توکن مشخص شده: Sol پنج دلار ورودی و سی دلار خروجی، Terra دو و نیم دلار ورودی و پانزده دلار خروجی، و Luna یک دلار ورودی و شش دلار خروجی. یک تغییر کوچک ولی کاربردی هم در کشینگ پرامپت آمده: حالا می‌توان نقطه‌ی cache مشخص کرد و حداقل عمر کش به سی دقیقه رسیده، با این تفاوت که نوشتن در کش این‌بار ۱.۲۵ برابر نرخ معمولی ورودی هزینه دارد.

اگر شایعات و گزارش‌های قبل از انتشار رسمی را هم در نظر بگیری (که در روزهای منتهی به این پیش‌نمایش زیاد بودند)، رقابت اصلی روی همین نکته است: آنتروپیک به‌خاطر همان نوع محدودیت دولتی، فعلاً مدل Mythos-tier خودش را در دسترس عموم ندارد، و OpenAI به‌وضوح می‌خواهد از این فاصله استفاده کند. این‌که این محدودیت چقدر طول می‌کشد و چه زمانی Sol، Terra و Luna واقعاً به دست همه می‌رسند، چیزی است که باید منتظرش ماند.

شخصی‌سازی بیشتر، با کنترل بیشتر

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

همراه این تغییر، یک قابلیت به اسم «منابع حافظه» (memory sources) هم به همه‌ی مدل‌ها اضافه شده: می‌توانی ببینی هر پاسخ شخصی‌سازی‌شده دقیقاً از چه چیزی (مکالمه‌ی قبلی، فایل، یا حافظه‌ی ذخیره‌شده) استفاده کرده، و در صورت نیاز آن را حذف یا اصلاح کنی. این یعنی شخصی‌سازی دیگر یک جعبه‌ی سیاه نیست؛ هرچند OpenAI خودش هم گفته این نمایش هنوز کامل نیست و ممکن است همه‌ی منابعی که واقعاً استفاده شده‌اند را نشان ندهد.

از کی در دسترسه

GPT-5.5 Instant از همین حالا به‌عنوان مدل پیش‌فرض برای همه‌ی کاربران چت‌جی‌پی‌تی فعال شده و در API هم با نام chat-latest در دسترس است. کاربرانی که پلن پولی دارند، تا سه ماه دیگر همچنان می‌توانند از طریق تنظیمات مدل به GPT-5.3 Instant دسترسی داشته باشند، قبل از این‌که این نسخه کاملاً بازنشسته شود.

شخصی‌سازی پیشرفته‌تر (با فایل‌ها و جیمیل) فعلاً برای کاربران Plus و Pro روی وب در حال رول‌اوت است و به‌زودی به موبایل و بقیه‌ی پلن‌ها هم می‌رسد. قابلیت منابع حافظه هم به‌مرور برای همه‌ی پلن‌ها فعال می‌شود، با این تفاوت که سرعت دسترسی ممکن است بسته به منطقه‌ی جغرافیایی فرق کند.