فریمورک

تیم Svelte روز ۱ اکتبر ۲۰۲۶ نسخه‌ی پایدار SvelteKit 3 رو منتشر کرد، حدود هفت هفته بعد از release candidate که ۱۳ آگوست اومده بود. این یه major release واقعیه و چند تا breaking change داره که تقریباً هر پروژه‌ی SvelteKit رو درگیر می‌کنه؛ خبر خوب اینه که یه ابزار migration رسمی هم همراهشه.

چه چیزهایی عوض شده؟

بزرگ‌ترین تغییر، جابه‌جایی کانفیگ پروژه‌ست: تنظیمات SvelteKit دیگه توی فایل svelte.config.js نیست و باید توی فایل vite.config.ts قرار بگیره. تغییر دوم که حتماً توی کدت حسش می‌کنی، جایگزین شدن alias معروف lib با subpath import های استاندارد Node.js هست، یعنی importها از پیشوند دلار به پیشوند هشتگ تغییر می‌کنن. alias های دیگه مثل app و env همچنان با پیشوند دلار می‌مونن، پس یه مدت با یه قرارداد ترکیبی کار می‌کنی:

// قبل از SvelteKit 3
import { formatDate } from '$lib/utils';

// SvelteKit 3
import { formatDate } from '#lib/utils';

علاوه بر این، فایل tsconfig پروژه حالا باید از یه مسیر جدید در app/tsconfig ارث‌بری کنه، به‌جای فایل تولیدشده توی پوشه‌ی svelte-kit. پیاده‌سازی service worker ها هم ساده‌تر شده و تنظیماتشون رو از ماژول‌های app میگیرن.

قابلیت‌های تازه

متغیرهای محیطی حالا یه قابلیت پایدار و درجه‌یک هستن (قبلاً experimental بودن). توی نسخه‌ی جدید، متغیرها رو توی یه فایل مشخص با کتابخونه‌های سازگار با Standard Schema مثل Zod، Valibot یا ArkType تعریف می‌کنی و اعتبارسنجی موقع استارت اپ انجام میشه، یعنی خطای کانفیگ همون اول معلوم میشه، نه وسط اجرا.

مدیریت خطا هم یکپارچه‌تر شده: کامپوننت error هم خطاهای load و هم خطاهای render رو مدیریت می‌کنه، همه‌ی خطاها از طریق handleError عبور می‌کنن، و stack trace ها حالا sourcemap دارن که دیباگ production رو راحت‌تر می‌کنه. shallow routing هم به‌جای API قبلی، با goto و گزینه‌ی shallow انجام میشه.

مهاجرت از نسخه‌ی قبلی

تیم Next.js در ۲۲ سپتامبر ۲۰۲۶ یک out-of-band security release منتشر کرد. این آپدیت یک آسیب‌پذیری Critical با امکان Remote Code Execution در پیاده‌سازی Node.js مربوط به ImageResponse در next/og رو برطرف می‌کنه.

نسخه‌های 16.2.0 تا قبل از 16.3.6 تحت تأثیر این آسیب‌پذیری هستن. مشکل از escaping نامناسب SVG تولیدشده توسط Satori و dependencyهای مرتبط ناشی می‌شه.

نسخه‌های patched:
next@16.3.6

برای شاخه‌ی 15 هم نسخه‌ی 15.5.26 منتشر شده که شامل hardening مرتبطه؛ خود Next.js اعلام کرده که شاخه‌ی 15 تحت تأثیر RCE اصلی نبوده.

اگر از Next.js 16.2.x استفاده می‌کنید، آپدیت به 16.3.6 توصیه می‌شه:

npm install next@16.3.6

همچنین Next.js اعلام کرده یک security release برنامه‌ریزی‌شده‌ی دیگر برای ۳۰ سپتامبر در راهه که شامل نسخه‌های 16.3.7 و 15.5.27 و ۹ آسیب‌پذیری دیگه خواهد بود.

تیم Laravel نسخه‌ی 13.33.0 رو در ۲۳ سپتامبر منتشر کرد. این نسخه قابلیت‌های جدیدی برای cache و Eloquent اضافه می‌کنه.

مهم‌ترین تغییرات شامل پشتیبانی Cache::memo() از tagged cache، attribute جدید #[Refreshes] برای reload کردن مقادیری که database بعد از write تولید می‌کنه، پشتیبانی inplace() برای بعضی index migrationها، پشتیبانی از valkey:// و valkeys:// و چندین bug fix در Queue، Redis، Eloquent و Artisan هست.

#[Refreshes] مخصوصاً برای generated columns مثل storedAs و virtualAs کاربردیه و باعث می‌شه بعد از create() یا update() فقط columnهای مشخص‌شده دوباره از database خوانده بشن.

نسخه‌ی 12.0.6 از Nest CLI در ۲۴ سپتامبر منتشر شد. این release شامل آپدیت @rspack/core به نسخه‌ی 2.2.7 و چند اصلاح در compiler هست.

از جمله تغییرات این نسخه می‌شه به resolve کردن TypeScript path aliasها از مسیر tsconfig، امکان جلوگیری از restart شدن application هنگام تغییر بعضی assetها و resolve شدن SWC source root به‌صورت مستقل برای هر application اشاره کرد.

اگر از Nest 12 استفاده می‌کنید، می‌تونید CLI رو با npm install -g @nestjs/cli@latest آپدیت کنید.

تیم NestJS نسخه‌ی 12.1.0 رو در ۲۳ سپتامبر منتشر کرد. این نسخه بیشتر روی bug fix و بهبود رفتار core و microservices تمرکز داره.

از تغییرات مهم می‌شه به بهبود inheritance برای constructorهای optional، نام‌گذاری بهتر moduleها در metadataهای نامعتبر، retry شدن Redis client بعد از connection failure، مدیریت بهتر pending requestها در microservices، پشتیبانی از چند global prefix، cookie support مستقل از adapter و پشتیبانی از multipart file upload در Fastify اشاره کرد.

در کنار این‌ها، CSRF protection و security headers داخلی هم اضافه شدن.

تیم Laravel نسخه‌ی 13.31.0 را در ۹ سپتامبر منتشر کرد. این نسخه چند قابلیت جدید برای Queue و Eloquent اضافه کرده؛ از جمله متد Queue::totalSize() برای مشاهده‌ی تعداد کل jobهای موجود در یک queue، رویداد JobInterrupted برای مدیریت jobهایی که توسط worker متوقف می‌شوند و پشتیبانی از chaperone() در روابط BelongsToMany با custom pivot model.

در این نسخه همچنین متد devServerUrl() به Vite اضافه شده، assertionهای ساده‌تر assertSentOnce و assertQueuedOnce برای Mail و Notification در دسترس قرار گرفته و چندین باگ در Queue، Redis، Eloquent، HTTP Client و بخش‌های مختلف فریم‌ورک برطرف شده است.

اگر از Laravel 13 استفاده می‌کنی، این نسخه مجموعه‌ای از قابلیت‌ها و bug fixهای جدید را در اختیار قرار می‌دهد.

تیم Laravel نسخه‌ی 1.0 پکیج Laravel MCP را در ۱۵ سپتامبر منتشر کرد؛ اولین نسخه‌ی stable این پکیج برای ساخت Model Context Protocol (MCP) Server در اپلیکیشن‌های Laravel. این نسخه از پروتکل MCP 2026-07-28 پشتیبانی می‌کند و به اپلیکیشن‌ها اجازه می‌دهد ابزارها و داده‌های خود را در اختیار AI applications قرار دهند.

از قابلیت‌های مهم این نسخه می‌توان به Searchable Tool Catalogs برای جست‌وجوی ابزارها در صورت نیاز، Cache Hints برای مشخص‌کردن نحوه‌ی cache شدن پاسخ‌ها، پشتیبانی از Stateless Server و تغییرات OAuth شامل الزام PKCE اشاره کرد. همچنین پشتیبانی از MCP Apps در extensions اضافه شده است.

اگر از نسخه‌ی 0.9 مهاجرت می‌کنی، باید نحوه‌ی ارسال requestها و headerهای MCP را بررسی کنی؛ نسخه‌ی 1.0 تغییراتی در protocol headers، session handling و بعضی APIها ایجاد کرده است.

تیم Django در ۲۲ سپتامبر اعلام کرد که DEP 19 توسط Steering Council و هیئت‌مدیره‌ی Django Software Foundation تصویب شده و ساختار جدید Technical Governance پروژه از این پس مبنای مدیریت فنی Django خواهد بود.

هدف اصلی این تغییر، ساده‌تر و قابل‌دسترس‌تر کردن فرآیند مدیریت فنی پروژه است. یکی از تغییرات مهم هم بازتعریف شرایط عضویت در Steering Council است تا طیف گسترده‌تری از اعضای جامعه بتوانند واجد شرایط عضویت و نامزدی در این شورا باشند.

در مرحله‌ی بعد، مستندات Django و djangoproject.com بر اساس ساختار جدید به‌روزرسانی می‌شوند و DEP 19 وارد وضعیت نهایی خواهد شد.

تیم Laravel نسخه‌ی 13.30.0 رو در ۱ سپتامبر منتشر کرد. این release چند قابلیت و بهبود جدید داره؛ از جمله اضافه‌شدن chunkBy() به Collection و Lazy Collection برای گروه‌بندی آیتم‌های مجاور، امکان نمایش دلیل توقف worker در خروجی queue:work، پشتیبانی از DSNهای sqlsrv: برای SQL Server و متدهای totalPendingSize()، totalDelayedSize() و totalReservedSize() برای Cloud Queue. همچنین Storage::path() حالا مسیرهایی که از root دیسک خارج می‌شن رو رد می‌کنه و DevCommands امکان صرف‌نظر کردن از vendor و default commands رو فراهم می‌کنه.

اگه از Laravel 13 استفاده می‌کنی، می‌تونی dependency رو به 13.30.0 ارتقا بدی تا این قابلیت‌ها و اصلاحات رو دریافت کنی.

تیم NestJS نسخه‌ی 12.0.4 رو در ۲۱ سپتامبر منتشر کرد. این یه patch release هست و بیشتر تمرکزش روی رفع باگ‌های بخش microservices قرار داره؛ از جمله retry شدن Kafka بعد از connection failure، مدیریت درخواست‌های pending در RabbitMQ و NATS هنگام بسته‌شدن client، مدیریت بهتر namespaceهای ناقص در gRPC و اصلاح نحوه‌ی handling خطاهای message handlerها. همچنین چند مشکل مربوط به spanهای request/response و یک مشکل در core که می‌تونست باعث hang شدن sparse factory injection بشه برطرف شده. در کنار این‌ها، پشتیبانی از multer limits بهبود پیدا کرده و fastify هم به نسخه‌ی 5.12.5 آپدیت شده. اگر از NestJS 12 استفاده می‌کنی، ارتقا به 12.0.4 برای دریافت این bug fixها توصیه می‌شه.

تیم Gin نسخه‌ی 1.12.0 رو منتشر کرد. این release چند قابلیت جدید و مجموعه‌ای از بهبودهای performance و bug fix رو به همراه داره؛ از جمله پشتیبانی از BSON در render، متدهای جدید GetError و GetErrorSlice و Delete در Context، پشتیبانی از encoding.UnmarshalText در URI و query binding و امکان استفاده از escaped path در routing. علاوه بر این، چند بهینه‌سازی برای router و recovery انجام شده و چند مشکل از جمله resource leak در RunFd و panic در بعضی مسیرهای routing برطرف شده. حداقل نسخه‌ی موردنیاز Go هم در این release به Go 1.25 افزایش پیدا کرده.

اگه از Gin استفاده می‌کنی، برای دریافت این تغییرات می‌تونی dependency رو به نسخه‌ی 1.12.0 ارتقا بدی.

تیم NestJS نسخه‌ی 12.0.3 رو در ۱۵ سپتامبر منتشر کرد. این یه patch release هست و تغییر اصلیش مربوط به بخش microservices میشه؛ در این نسخه مشکلی برطرف شده که باعث می‌شد Kafka processing end hook همیشه اجرا نشه.

اما بخش مهم‌تر این release، هم‌زمانی اون با چند Security Advisory جدیده. در ۱۵ سپتامبر سه آسیب‌پذیری برای NestJS منتشر شد: یکی امکان Remote Process Termination از طریق پیام‌های عمیقاً تو‌در‌تو در microserviceها، یکی Path-scoped Middleware Bypass از طریق absolute-form request target و دیگری Unbounded Memory Growth در TCP microservice transport. دو مورد اول با شدت High و مورد سوم با شدت Moderate ثبت شده‌اند.

اگه از NestJS و مخصوصاً @nestjs/microservices استفاده می‌کنی، بهتره وضعیت dependencyهات رو بررسی کنی و نسخه‌های اصلاح‌شده رو در پروژه اعمال کنی؛ مخصوصاً اگر از Kafka، TCP transport یا Fastify middleware استفاده می‌کنی.

یه الگوی خیلی رایج توی پروژه‌های Next.js اینه که backend رو هم همون‌جا، توی پوشه‌ی app/api یا pages/api، پیاده می‌کنن. برای یه پروژه‌ی کوچیک یا یه MVP این کار کاملاً منطقیه — چرا یه سرور جدا راه بندازی وقتی همون فریم‌ورک فرانت‌اند می‌تونه چند تا endpoint هم سرو کنه؟ ولی وقتی پروژه بزرگ‌تر میشه، وقتی تعداد endpoint ها از چند تا به چند ده تا میرسه، وقتی نیاز به background job و queue و اتصال به چند تا سرویس خارجی پیدا می‌کنی، همون سادگی اولیه تبدیل به یه مشکل میشه. اینجاست که NestJS وارد بازی میشه.

NestJS دقیقاً چیه؟

NestJS یه فریم‌ورک backend برای Node.js هست که روی TypeScript ساخته شده (هرچند جاوااسکریپت خالص هم پشتیبانی میشه) و زیرش از Express یا Fastify به‌عنوان HTTP server استفاده می‌کنه — خودت انتخاب می‌کنی کدومو بخوای. تفاوت اصلیش با یه فریم‌ورک minimal مثل Express اینه که NestJS یه معماری کامل و opinionated روی سرت میذاره: ماژول‌ها، کنترلرها، provider ها (سرویس‌ها)، و یه سیستم dependency injection که کل این‌ها رو به هم وصل می‌کنه.

یه مثال ساده از یه ماژول در NestJS این شکلیه:

// users.controller.ts
import { Controller, Get, Post, Body, Param } from '@nestjs/common';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get(':id')
  findOne(@Param('id') id: string) {
    return this.usersService.findOne(id);
  }

  @Post()
  create(@Body() createUserDto: CreateUserDto) {
    return this.usersService.create(createUserDto);
  }
}

// users.service.ts
import { Injectable } from '@nestjs/common';

@Injectable()
export class UsersService {
  private users = [];

  findOne(id: string) {
    return this.users.find((u) => u.id === id);
  }

  create(data: CreateUserDto) {
    const user = { id: Date.now().toString(), ...data };
    this.users.push(user);
    return user;
  }
}

تیم PyTorch نسخه‌ی ۲.۱۴ رو منتشر کرد، این‌بار با یه چرخه‌ی انتشار کوتاه‌تر از معمول (حدود سه هفته از branch-cut تا release). این نسخه بیشتر روی محاسبات توزیع‌شده، سازگاری با شتاب‌دهنده‌های بیشتر، و چند تا بهبود performance تمرکز داره تا یه تغییر بنیادی توی API.

توزیع‌شدگی و fault tolerance

یکی از بخش‌های اصلی این نسخه، یه backend جدید برای PyTorch Distributed به اسم nccl2 هست که از torchcomms پورت شده و کل قرارداد collective رو با communicator های nonblocking و قابلیت eager splitting پیاده‌سازی می‌کنه. کنار اون، fault tolerance حالا به یه مفهوم اول‌درجه توی c10d تبدیل شده: امکان reconfigure کردن process group به‌صورت in-place، پشتیبانی از one-sided RMA window، و یه Flight Recorder که برخلاف قبل فقط مخصوص NCCL نیست و برای هر backend ای کار می‌کنه.

یه ویژگی جالب دیگه، compile-on-one-rank هست. توی یه job توزیع‌شده، قبلاً هر rank مدل رو جداگانه compile می‌کرد، یعنی یه compile چند دقیقه‌ای N بار پرداخت می‌شد. حالا با این تغییر، artifact کامپایل‌شده روی یه device قابل استفاده روی device های دیگه هم هست — یعنی یه کرنل که روی cuda:0 کامپایل شده، می‌تونه مستقیم روی cuda:3 هم لود و اجرا بشه.

پلتفرم‌ها و سخت‌افزار بیشتر

پشتیبانی از پایتون ۳.۱۵ و نسخه‌ی free-threaded (بدون GIL) آن، یعنی 3.15t، حالا به ویندوز و مک‌اواس هم گسترش پیدا کرده و پوشش کامل ماتریس انتشار PyTorch رو تکمیل می‌کنه. این پشتیبانی فعلاً فقط در سطح binary و eager runtime هست؛ torch.compile هنوز روی پایتون ۳.۱۵ کار نمی‌کنه.

روی سخت‌افزار هم چند تا خبر هست: اپل سیلیکون جبر خطی native گرفته، شامل SVD مبتنی بر Jacobi kernel، eigh، QR و Cholesky، به‌همراه بازنویسی پنج‌بخشی عملیات reduction. سمت AMD، wheel های ROCm 7.14 حالا از طریق TheRock pip SDK ساخته میشن. اینتل XPU هم قابلیت native graph capture گرفته، و Inductor حالا از معماری Rubin (sm_107) انویدیا هم پشتیبانی می‌کنه.

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

یه ویژگی به اسم NVGEMM هم اضافه شده که کرنل‌های CUTLASS تولیدشده با CuTeDSL رو به Inductor میاره، با epilogue fusion، پشتیبانی از GEMM مقیاس‌شده و NVFP4، و autotuning این کرنل‌ها کنار Triton و ATen. علاوه بر این، پشتیبانی آزمایشی torch.compile از تانسورهای complex-valued هم اضافه شده که عملیات پیچیده رو به عملیات پشتیبانی‌شده‌ی موجود decompose می‌کنه.