الكتابات/blog/2026/07
Blog28 يوليو 2026·6 دقيقة

TypeScript 7 (مشروع Corsa): دليل المترجم الأسرع 10 مرات بلغة Go

أطلقت Microsoft نسخة TypeScript 7 مع إعادة كتابة كاملة للمترجم بلغة Go — بناء أسرع 10 مرات وذاكرة أقل بنسبة 70%. دليل الترقية والتوافق مع Next.js وVue.

في الثامن من يوليو 2026، أصدرت Microsoft نسخة TypeScript 7 — وهو إصدار تاريخي يُغلق فصلاً كاملاً من تطوير أدوات JavaScript. بعد أكثر من عام من المعاينات العلنية تحت مسمى المشروع الداخلي "Corsa"، شحنت Microsoft إعادة كتابة كاملة للمترجم بلغة Go، مما أسفر عن سرعة بناء أعلى بنحو 10 مرات دون أي تغيير في نظام الأنواع. بالنسبة للفرق التي تعاني من عمليات التحقق من الأنواع التي تستغرق دقائق على قواعد البيانات الكبيرة، هذا تحول جذري.

ما هو مشروع Corsa؟

مشروع Corsa هو الاسم الداخلي لجهد Microsoft لنقل المترجم الكامل لـ TypeScript — المحلل، والرابط، ومدقق الأنواع، والمُصدر، وخدمة اللغة — من JavaScript إلى Go. أُعلن عن المبادرة في أواخر عام 2025 وشحن إصداره المستقر باعتباره TypeScript 7.0.

كان الدافع جوهريًا: مترجم TypeScript يعمل على Node.js، الذي يعمل بخيط تنفيذ واحد بطبيعته. بغض النظر عن مدى قوة الجهاز، لم يكن بإمكان المترجم القديم استخدام سوى نواة معالج واحدة. نموذج goroutines والذاكرة المشتركة في Go يتيح للمترجم الجديد توزيع العمل عبر جميع الأنوية المتاحة، مما يجعله يتوسع مع الأجهزة بدلاً من أن يكون محدودًا بها.

ما مدى السرعة؟ الأرقام الحقيقية

التحسينات ليست تدريجية. نشر Daniel Rosenwasser، مدير المنتج لـ TypeScript، أرقامًا ملموسة عند الإطلاق:

  • قاعدة كود VS Code (مليون ونصف سطر): انخفض التحقق من الأنواع من 89 ثانية إلى أقل من 9 ثوانٍ — أسرع بنحو 10 مرات
  • Monorepo React كبير: من 133 ثانية إلى 16 ثانية (أسرع 8 مرات)
  • تطبيق Next.js نموذجي: من 5 إلى 15 مرة أسرع حسب حجم المشروع

انخفض استخدام الذاكرة أيضًا بشكل ملحوظ. يستخدم مترجم Go حوالي 60 إلى 70 بالمئة ذاكرة أقل من نسخة Node.js، وهو أمر مهم على أجهزة تشغيل CI ذات موارد محدودة.

جهاز يحتوي على 8 أنوية معالجة يؤدي الآن ما يقارب 8 أضعاف العمل في الثانية مقارنةً بمترجم Node.js ذي الخيط الواحد. هذه العلاقة التوسعية هي الإنجاز المعماري الجوهري.

كيف تعمل إعادة الكتابة بـ Go

TypeScript 7 ليس لغة جديدة أو نظام أنواع جديد. الصياغة التي تكتبها، والقواعد التي يفرضها، ومخرجات .d.ts التي ينتجها — كلها متطابقة مع TypeScript 5 و6. ما تغير هو ما يحدث عند تشغيل tsc.

المترجم القديم كان برنامج JavaScript. كان يحلل ملفاتك، ويبني شجرة AST، ويشغّل استنتاج الأنواع، ويصدر JavaScript — كل ذلك في خيط تنفيذ واحد على Node.js. المترجم الجديد هو ثنائي Go مترجم يؤدي نفس العمل المنطقي ولكنه:

  1. يعمل بشكل أصلي — لا بدء تشغيل V8، ولا إحماء JIT، بل تنفيذ مباشر على نظام التشغيل
  2. يستخدم التوازي الحقيقي — تتحقق goroutines من الأنواع في الملفات المستقلة بشكل متزامن
  3. يدير الذاكرة بكفاءة — مُخصص Go مُصمم خصيصًا لهذا النوع من العمل

خلال فترة المعاينة، كان مترجم Go متاحًا كـ tsgo عبر @typescript/native-preview. اعتبارًا من الإصدار 7.0، يُشحن كـ tsc الافتراضي.

ما الذي تغير: التغييرات الجذرية والإعدادات الافتراضية الجديدة

كان TypeScript 6 هو إصدار الجسر المقصود — فعّل إعدادات افتراضية أكثر صرامة وأهمل الخيارات القديمة حتى تتمكن الفرق من التنظيف قبل الترقية إلى 7.0. إذا تخطيت TypeScript 6، فإن تلك التحذيرات أصبحت الآن أخطاء.

الوضع الصارم مُفعَّل افتراضيًا

strict: true هو الآن الإعداد الافتراضي. أي مشروع اعتمد على الإعداد الافتراضي المتساهل القديم سيرى أخطاء جديدة عند الترقية. الحل صريح — أضف "strict": false للإلغاء، أو عالج الثغرات في الأنواع واحدة تلو الأخرى.

تغير الهدف إلى ES2022

تحول هدف التجميع الافتراضي من ES3 إلى ES2022. الكود الذي اعتمد على TypeScript لإصدار polyfills لـ ES3 يحتاج إلى "target": "ES3" صريح في tsconfig.json.

تحديث إعدادات دقة الوحدات

moduleResolution يتخذ الآن "bundler" افتراضيًا لمعظم الإعدادات، وverbatimModuleSyntax يتخذ true افتراضيًا. إذا كانت قاعدة كودك تستخدم import type بشكل غير متسق، ستظهر أخطاء عند وقت التحقق من الأنواع.

أخطاء صارمة على الخيارات المهملة

خيارا importsNotUsedAsValues وpreserveValueImports يُسببان الآن أخطاء صارمة. احذفهما من tsconfig.json واستخدم الإعداد الموحد الجديد:

{
  "compilerOptions": {
    "moduleResolution": "bundler",
    "strict": true,
    "verbatimModuleSyntax": true
  }
}

واجهة برمجة الإضافات غير متوافقة

إذا كان مشروعك يستخدم إضافات مترجم TypeScript — transformer plugins، أو ts-patch، أو ما شابهها — فإنها لن تعمل مع مترجم Go. كانت واجهة برمجة الإضافات تعتمد على سطح API بـ JavaScript الذي لم يعد موجودًا. يعمل مطورو الإضافات بنشاط على شحن معادلات بـ Go.

توافق الأدوات

لا تعمل جميع الأدوات المرتبطة بـ TypeScript مع المترجم الجديد بعد:

الأداةالحالة
ts-nodeتحتاج تحديث — تعتمد على JS API لـ TS
ts-jestتحتاج تحديث — تعتمد على JS API لـ TS
ts-morphتحتاج تحديث — تعتمد على JS API لـ TS
ESLint مع قواعد TypeScriptتعمل — تستخدم معلومات الأنواع عبر API منفصل
بناء tsc المباشرمدعوم بالكامل
وضع المراقبة (--watch)قادم في TypeScript 7.1

توافق الأطر

Next.js

يعمل Next.js مع TypeScript 7 للبناء، لكن تكامل tsgo الأصلي الكامل متوقع في الربع الثالث من 2026. في غضون ذلك، افصل التحقق من الأنواع عن عملية البناء:

// next.config.ts
const config = {
  typescript: {
    ignoreBuildErrors: true,
  },
};
 
export default config;

ثم شغّل tsc --noEmit كخطوة CI مستقلة إلى جانب البناء.

Vue وSvelte وAstro وMDX

يجب على الفرق التي تستخدم Vue أو Svelte أو Astro أو MDX انتظار TypeScript 7.1. يفتقر مترجم Go إلى واجهة برمجة مُبرمَجة تعتمد عليها هذه الأطر لتكامل المحرر ومعالجة الملفات. استخدام TypeScript 7.0 مع هذه الأطر سيكسر دعم IDE.

VS Code

خدمة اللغة — الجزء الذي يُشغّل IntelliSense وتلميحات الأنواع والانتقال إلى التعريف — لا تزال في طور النقل إلى Go. من المتوقع أن تصل خدمة اللغة المبنية على Go في أواخر 2026 أو مطلع 2027. حتى ذلك الحين، يستمر VS Code في استخدام الخدمة المبنية على JavaScript.

تثبيت TypeScript 7

npm install -D typescript@7

للتحقق من مترجم Go قبل الالتزام الكامل:

npm install -D @typescript/native-preview
npx tsgo --noEmit

شغّل tsgo جنبًا إلى جنب مع tsc الحالي للمقارنة. عند تطابق النتائج، يمكنك التبديل إلى المترجم الجديد.

مسار الترقية: ثلاث خطوات

الخطوة الأولى — الترقية إلى TypeScript 6 أولاً

TypeScript 6 هو إصدار الجسر المطلوب. يحوّل أخطاء الإصدار 7.0 إلى تحذيرات أولاً، مما يتيح لك إصلاحها تدريجيًا.

npm install -D typescript@6
npx tsc --noEmit
# أصلح جميع التحذيرات قبل المتابعة

الخطوة الثانية — تشغيل مترجم Go بالتوازي

npm install -D @typescript/native-preview
npx tsgo --noEmit   # مترجم Go
npx tsc --noEmit    # مترجم JS — قارن المخرجات

يجب أن ينتج كلاهما أخطاء متطابقة. أي اختلافات هي أخطاء برمجية — أبلغ عنها في مستودع TypeScript على GitHub.

الخطوة الثالثة — التبديل إلى TypeScript 7

npm install -D typescript@7

حدّث سكريبت CI ليشغّل tsc --noEmit كخطوة تحقق من الأنواع مستقلة بالكامل عن البناء.

ما القادم في TypeScript 7.1

حدد فريق TypeScript عدة ميزات لإصدار 7.1:

  • وضع المراقبة (--watch) — الفجوة الرئيسية في 7.0 لسير عمل التطوير المحلي
  • واجهة البرمجة المُبرمَجة — تُلغي قيود Vue وSvelte وAstro وMDX
  • خدمة لغة VS Code في Go (معاينة)
  • طبقات التوافق لـ ts-node وts-morph

غياب وضع المراقبة في 7.0 هو الفجوة الأكثر وضوحًا في التطوير اليومي. حتى صدور 7.1، احتفظ بـ tsc --watch القديم عبر devDependencies منفصل يشير إلى TypeScript 6.

الصورة الأكبر

تُغير إعادة الكتابة بـ Go اقتصاديات TypeScript على نطاق واسع. تستطيع الـ monorepos التي تضم مئات الحزم، والتي كانت تتطلب خوادم تحقق مخصصة، إتمام بنائها الكامل في الوقت الذي كان يستغرقه فحص حزمة واحدة سابقًا. فواتير CI تنخفض. دورات التغذية الراجعة للمطورين تتسارع.

TypeScript 7 لا يغير ما تكتبه. يغير مدى سرعة اكتشاف الأدوات لأخطائك. بالنسبة لمعظم الفرق، هذه هي المقايضة الصحيحة: لا تكلفة هجرة على نظام الأنواع، وتحسينات جوهرية على تجربة العمل فيه كل يوم.