مهاجرت به TypeScript 7؛ سرعت 10 برابری، تغییرات مهم و دام های سازگاری

TypeScript 7 در 8 ژوئیه 2026 با یک بازنویسی Native به زبان Go منتشر شد و در Buildهای کامل معمولاً سرعتی حدود 8 تا 12 برابر ارائه می کند. اما مهاجرت فقط نصب نسخه جدید نیست: API کامپایلر فعلاً در 7.0 وجود ندارد، بعضی Frameworkها هنوز به Language Server Plugin وابسته اند و Defaultهای نسخه 6 اکنون جدی تر اعمال می شوند.

در یک نگاه

• TypeScript 7 بازنویسی Native ابزارها به Go است، نه یک Syntax کاملاً تازه.
• مایکروسافت در Buildهای نمونه سرعت 7.7 تا 11.9 برابر و کاهش مصرف تجمیعی حافظه گزارش کرده است.
• نسخه 7.0 API برنامه نویسی Compiler ندارد؛ API تازه برای 7.1 برنامه ریزی شده است.
• بسته @typescript/typescript6 برای اجرای همزمان نسخه 6 و 7 ارائه شده است.
• strict، module: esnext، types: [] و rootDir جدید از تغییرات مهم Default هستند.
• گزینه های قدیمی مانند target: es5، moduleResolution: node10 و baseUrl دیگر پشتیبانی نمی شوند.

TypeScript 7 دقیقاً چه تغییری کرده است؟

تغییر اصلی TypeScript 7 در معماری پیاده سازی است. ابزارهای TypeScript سال ها با خود TypeScript و JavaScript اجرا می شدند. تیم مایکروسافت برای استفاده بهتر از چند هسته، حافظه مشترک و سرعت Native، کدبیس را با حفظ منطق و ساختار اصلی به Go منتقل کرد. هدف این بود که نتیجه Type Checking تا حد ممکن با نسخه قبلی سازگار بماند، اما زمان Parse، Check، Emit و پاسخ Language Server به طور چشمگیری کاهش پیدا کند. بنابراین ارزش نسخه 7 بیشتر در مقیاس، CI و تجربه Editor دیده می شود.

این بازنویسی به معنی کنارگذاشتن JavaScript یا تغییر مدل Type System نیست. فایل های .ts، tsconfig و بیشتر رفتارهای زبان همان قرارداد آشنا را دنبال می کنند. تفاوت آنجاست که موتور زیرین اکنون Native، چندریسمانی و دارای بهینه سازی های تازه است. تیم برای سازگاری، پروژه های بزرگ داخلی و خارجی را آزمایش کرده و زیرساخت تست Regression را نیز روی کدبیس جدید بازسازی کرده است. بااین حال، هر بازنویسی بزرگ مرزهای ناسازگار خود را دارد؛ به ویژه ابزارهایی که از API داخلی Compiler یا Pluginهای Language Server استفاده می کنند.

سرعت و حافظه در پروژه های واقعی

مایکروسافت برای چند پروژه متن باز اعداد Build کامل را منتشر کرده است. VS Code از 125٫7 ثانیه در TypeScript 6 به 10٫6 ثانیه در TypeScript 7 رسیده؛ Sentry از 139٫8 به 15٫7 ثانیه، Bluesky از 24٫3 به 2٫8 ثانیه، Playwright از 12٫8 به 1٫47 ثانیه و tldraw از 11٫2 به 1٫46 ثانیه کاهش یافته است. این اعداد Benchmark رسمی اند و تضمین نمی کنند هر پروژه دقیقاً همان نسبت را ببیند، اما نشان می دهند سود اصلی در کدبیس های بزرگ و Buildهای کامل قابل توجه است.

مصرف حافظه تجمیعی Build نیز در نمونه های رسمی کاهش یافته است: از 18 درصد برای VS Code تا 26 درصد برای Bluesky. این موضوع برای Runnerهای CI با Memory Limit، لپ تاپ های توسعه و Monorepoها اهمیت دارد. بااین حال، Parallelization می تواند Peak CPU را بالا ببرد و روی Runner مشترک، Jobهای همزمان را تحت فشار قرار دهد. پس فقط زمان یک فرمان را نبینید؛ CPU، Peak Memory، Queue Time و هزینه Runner را در کنار هم اندازه بگیرید.

Language Server نیز بازنویسی شده و مایکروسافت از کاهش بیش از 80 درصدی Commandهای ناموفق و بیش از 60 درصدی Crash نسبت به TypeScript 6 گزارش داده است. تیم هایی مانند Slack، Canva و بخش های داخلی مایکروسافت نیز بهبودهای بزرگ اعلام کرده اند. این داده ها امیدبخش اند، اما معیار اصلی شما باید Repository خودتان باشد. Cache، تعداد Project Reference، نوع Module Resolution، Pluginهای Editor و شکل Monorepo می توانند نتیجه را تغییر دهند.

مهم ترین محدودیت سازگاری

TypeScript 7.0 در زمان انتشار API برنامه نویسی Compiler ندارد. ابزارهایی که typescript را Import می کنند تا AST بسازند، Transform اجرا کنند یا Type Checker را مستقیم صدا بزنند، نمی توانند صرفاً نسخه Dependency را به 7 تغییر دهند. تیم TypeScript گفته API جدید و متفاوت برای 7.1 برنامه ریزی شده است. تا آن زمان، راه رسمی اجرای همزمان TypeScript 6 برای ابزارهای وابسته به API و TypeScript 7 برای tsc Native است.

دسته دوم محدودیت، Language Server Pluginها هستند. اکوسیستم هایی مانند Vue، Svelte، Astro و MDX برای تجربه کامل Editor به Pluginهایی متکی اند که هنوز با Language Server جدید هماهنگ نشده اند. راهنمای رسمی توصیه می کند این پروژه ها فعلاً TypeScript 6 را برای Editor نگه دارند. Angular می تواند ترکیب میانه داشته باشد: tsc نسخه 7 برای تشخیص سریع خطا در CLI و TypeScript 6 برای Editor. این وضعیت موقت است، اما برای برنامه مهاجرت امروز باید واقعی در نظر گرفته شود.

Defaultهای تازه و خطاهای مهاجرت

TypeScript 7 رفتار Type Checking و Command Line را با TypeScript 6 هماهنگ طراحی کرده، اما Defaultهای 6 را می پذیرد و گزینه های Deprecated را به خطای جدی تبدیل می کند. اگر پروژه مستقیماً از TypeScript 5 یا قدیمی تر می آید، بهتر است ابتدا روی 6 مهاجرت کند و Warningها را پاک کند. در TypeScript 7، strict به صورت پیش فرض true، module برابر esnext و target برابر نسخه پایدار ECMAScript پیش از esnext است. همچنین noUncheckedSideEffectImports فعال می شود.

دو تغییر types و rootDir برای بسیاری از پروژه ها غافلگیرکننده اند. types: [] یعنی TypeScript دیگر تمام پکیج های قابل مشاهده @types را به Global Scope وارد نمی کند. این رفتار Dependency پنهان را کم می کند، اما تست هایی که بدون تنظیم صریح از jest یا node استفاده می کنند خطا می گیرند. rootDir نیز از مسیر فایل tsconfig شروع می شود؛ اگر خروجی قبلاً بر پایه src چیده می شد، باید مقدار rootDir را صریح کنید تا ساختار dist ناخواسته عوض نشود.

{
  "compilerOptions": {
    "strict": true,
    "module": "esnext",
    "moduleResolution": "bundler",
    "rootDir": "./src",
    "outDir": "./dist",
    "types": ["node", "jest"],
    "noUncheckedSideEffectImports": true
  },
  "include": ["src"]
}

گزینه های قدیمی متعددی حذف یا بی اثر شده اند: target: es5، downlevelIteration، moduleResolution با node یا node10، moduleهای amd و umd و systemjs و none، baseUrl و moduleResolution: classic دیگر مسیر پشتیبانی شده نیستند. esModuleInterop و allowSyntheticDefaultImports را نمی توان false کرد و alwaysStrict عملاً true است. این تغییرها برای پاک سازی حالت های تاریخی طراحی شده اند، ولی پروژه های Legacy باید قبل از ارتقا مسیر Bundling و Runtime خود را روشن کنند.

اجرای همزمان TypeScript 6 و 7

برای ابزارهایی که هنوز Compiler API نسخه 6 را لازم دارند، بسته @typescript/typescript6 ارائه شده است. این بسته executable با نام tsc6 می دهد و API نسخه 6 را Export می کند. چون ابزارهایی مانند typescript-eslint ممکن است Dependency را با نام typescript انتظار داشته باشند، مایکروسافت استفاده از npm alias را پیشنهاد می کند. در این الگو، نام typescript به بسته سازگاری نسخه 6 اشاره می کند و یک Alias جدا برای Native نسخه 7 دارید.

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  },
  "scripts": {
    "typecheck:native": "tsc --noEmit",
    "typecheck:legacy": "tsc6 --noEmit",
    "test:types": "npm run typecheck:legacy && npm run typecheck:native"
  }
}

نام دقیق Executable و Resolution بسته را در محیط خود آزمایش کنید؛ Script بالا الگوی مفهومی همان Alias رسمی است و ممکن است Package Manager یا Workspace شما نیاز به تنظیم جزئی داشته باشد. هدف این است که ابزارهای مبتنی بر API همچنان typescript نسخه 6 را ببینند، درحالی که Build Native نسخه 7 جدا اجرا شود. Lockfile را Commit کنید و در CI دقیقاً همان Package Manager و نسخه را به کار ببرید.

برنامه مهاجرت مرحله به مرحله

1. نسخه فعلی TypeScript، Framework، Editor Plugin و ابزارهای وابسته به Compiler API را فهرست کنید.
2. پروژه را ابتدا روی آخرین TypeScript 6 سبز کنید و Deprecated Optionها را حذف کنید.
3. Baseline زمان Build، Type Check، حافظه، CPU و نرخ خطای Editor را ثبت کنید.
4. TypeScript 7 را در Branch مستقل نصب و tsc --noEmit را روی کل Workspace اجرا کنید.
5. Defaultهای types، rootDir، strict و moduleResolution را صریح کنید.
6. Editor را جدا آزمایش کنید و در پروژه Plugin-based، سناریوی Side-by-Side بسازید.
7. CI را با نسخه 6 و 7 برای یک دوره موازی اجرا و اختلاف Diagnostics را ثبت کنید.
8. ابتدا یک Package یا Repository کم ریسک را Rollout کنید و سپس دامنه را گسترش دهید.

مقایسه Diagnostics باید ماشین خوان باشد. خروجی نسخه 6 و 7 را ذخیره کنید، خطاهای جدید را دسته بندی و موارد حذف شده را نیز بررسی کنید. تنها سبزشدن نسخه 7 کافی نیست؛ اگر نسخه 6 خطایی می داد و 7 ساکت شده، باید معلوم شود تغییر عمدی است یا Gap. برای پروژه های Library، Declaration Fileهای تولیدی را Diff کنید. برای App، Build Artifact، Tree Shaking و رفتار Runtime را با تست E2E بسنجید.

همچنین توسعه دهنده ها را وارد Pilot کنید. سرعت CLI یک بخش ماجراست؛ Completion، Rename، Find References، Navigation و Diagnostics زنده بخش مهم تجربه روزانه اند. یک فرم کوتاه برای زمان بازشدن Workspace، تاخیر Completion، Crash و ناسازگاری Plugin داشته باشید. بهبود واقعی باید هم در CI و هم در Editor دیده شود، مگر اینکه آگاهانه فقط tsc Native را وارد Pipeline کرده باشید.

Monorepo، CI و منابع پردازشی

TypeScript 7 Parse، Type Check و Emit را تا حد بیشتری موازی می کند. Flagهای آزمایشی --checkers و --builders برای تنظیم Parallelization و --singleThreaded برای خاموش کردن آن وجود دارند. روی لپ تاپ و Runner اختصاصی، Default احتمالاً بهترین نقطه شروع است. روی Runner مشترک با CPU Quota، اجرای چند Job TypeScript 7 همزمان ممکن است Throttling ایجاد کند. تعداد Worker، Matrix CI و Limit کانتینر را با داده تنظیم کنید.

در Monorepo، اول Build Graph را اصلاح کنید. سرعت Compiler نمی تواند Dependency Cycle، Project Reference اشتباه یا Rebuild بی دلیل را جبران کند. Cache Remote نیز باید بر پایه نسخه Compiler، tsconfig، Lockfile و ورودی های مرتبط Key شود. Artifact ساخته شده با TypeScript 6 و 7 را در یک Cache مشترک بدون Version Key قرار ندهید. اگر Pipeline همزمان دو نسخه را اجرا می کند، نام Artifact و گزارش ها را واضح جدا کنید.

چه پروژه ای الان مهاجرت کند؟

تصمیم نباید فقط براساس هیجان «10 برابر سریع تر» باشد. اگر Type Check پروژه 15 ثانیه است، صرفه جویی ممکن است ارزش پیچیدگی Side-by-Side را نداشته باشد. اگر CI هر Pull Request هشت دقیقه منتظر Type Check می ماند، فرصت اقتصادی و تجربه ای بسیار بزرگ تر است. Traffic Opportunity این موضوع نیز از همین سؤال واقعی می آید: کاربران نه فقط می خواهند بدانند TypeScript 7 سریع است، بلکه می خواهند بدانند پروژه خودشان امروز باید مهاجرت کند یا نه.

پرسش های متداول

آیا TypeScript 7 با npm install typescript نصب می شود؟

بله، نسخه پایدار از بسته استاندارد typescript در npm عرضه شده است. اما ابزارهای وابسته به API نسخه 6 ممکن است به بسته سازگاری و Alias نیاز داشته باشند.

آیا کد TypeScript 6 بدون تغییر Compile می شود؟

کدی که با TypeScript 6 و stableTypeOrdering فعال بدون Deprecated Option سبز باشد، هدف سازگاری نسخه 7 است. بااین حال Defaultهای جدید و حذف گزینه های قدیمی می توانند Migration لازم ایجاد کنند.

چرا Vue یا Svelte باید صبر کنند؟

تجربه Editor این Frameworkها به Language Server Plugin وابسته است و در زمان انتشار TypeScript 7.0 پشتیبانی کامل فراهم نبود. می توان آزمایش CLI انجام داد، اما جایگزینی کامل Editor توصیه نشده است.

آیا سرعت 10 برابر تضمینی است؟

خیر. 8 تا 12 برابر بازه معمول گزارش رسمی برای Build کامل چند پروژه بزرگ است. نتیجه به اندازه کدبیس، Cache، سخت افزار، تنظیمات و نوع کار بستگی دارد؛ Benchmark داخلی لازم است.

TypeScript 7 API Compiler دارد؟

نسخه 7.0 API برنامه نویسی Compiler ارائه نمی کند. تیم TypeScript برنامه API جدید را برای 7.1 اعلام کرده و برای دوره گذار اجرای همزمان نسخه 6 را فراهم کرده است.

جمع بندی

TypeScript 7 یک بهینه سازی کوچک نیست؛ بازسازی زیرساخت Compiler و Language Server برای سرعت Native و چندریسمانی است. پروژه های معمول React و Node می توانند همین حالا Pilot را آغاز کنند، اما Frameworkهای Plugin-based و ابزارهای Compiler API باید Side-by-Side یا صبر کنترل شده داشته باشند. قبل از Rollout، روی TypeScript 6 تمیز شوید، Defaultها را صریح کنید، Diagnostics و Artifactها را مقایسه کنید و سود واقعی CI و Editor را اندازه بگیرید.

منابع رسمی

• اعلام رسمی TypeScript 7.0، Benchmarkها و راهنمای سازگاری