TypeScript 6.0 RC: الميزات، والتغييرات الجذرية، وكيفية الاستعداد

الرئيسية » Python » TypeScript 6.0 RC: الميزات، والتغييرات الجذرية، وكيفية الاستعداد

وصل TypeScript 6.0 رسميًا إلى مرحلة الإصدار التجريبي (RC).وهذا ليس مجرد تحديث تدريجي آخر. إنها النسخة الرئيسية الأخيرة التي تعمل على تطبيق جافا سكريبت القديم للمترجم وخدمة اللغة، قبل أن ينتقل المشروع مباشرةً إلى محرك جديد كليًا قائم على لغة Go في TypeScript 7.0. هذا وحده يجعل الإصدار 6.0 إصدارًا محوريًا: إنه الجسر الذي يجب عبوره قبل أن يتغير كل شيء في جوهره.

يمكنك البدء بتجربة الإصدار التجريبي اليوم عن طريق تثبيته من npm مع:

npm install -D typescript@rc

تتمثل الفكرة الأساسية وراء TypeScript 6.0 في الإعداد والتوافقيُسهّل هذا الإصدار الانتقال من الإصدار 5.9 إلى 7.0، مع تحسين الإعدادات الافتراضية، وإلغاء بعض الميزات القديمة، وإضافة بعض الميزات المُستهدفة التي إما تُحاكي السلوك المستقبلي أو تُتيح إمكانيات JavaScript القادمة مثل Temporal وواجهات برمجة تطبيقات ES2025 وطرق "upsert" في Map. كما يتضمن بعض التعديلات الطفيفة على نظام الأنواع، وعلامات جديدة للمُصرّف، وإعدادات افتراضية ستؤثر حتمًا على المشاريع الحقيقية، خاصةً فيما يتعلق بـ types, rootDirوالصرامة.

TypeScript 6.0 كجسر إلى الإصدار 7.0 المبني على لغة Go

تم تصميم TypeScript 6.0 بشكل صريح ليكون الإصدار الرئيسي الأخير على قاعدة بيانات JavaScript الحاليةيعمل فريق TypeScript على إعادة كتابة المترجم وخدمة اللغة إلى محرك أصلي في جويستفيد هذا المحرك الجديد من الأداء الأصلي والتوازي في الذاكرة المشتركة. وسيظهر لأول مرة في TypeScript 7.0 وما بعده، ويأتي الإصدار 6.0 مباشرةً بعده كمرحلة انتقالية.

معظم التغييرات الجذرية وعمليات الإلغاء في الإصدار 6.0 تهدف إلى ضمان استمرارية عملية الترقية إلى الإصدار 7.0 في المستقبل.الخيارات التي لا يمكن دعمها بكفاءة في البنية الأصلية، وأنظمة الوحدات القديمة، والخصائص القديمة، إما يتم إزالتها أو يتم وضع علامة واضحة عليها بأنها مهملة مع وجود مخرج: يمكنك تعيين "ignoreDeprecations": "6.0" في الخاص tsconfig.json لإيقاف تشخيصات الإهمال في الإصدار 6.0. لكن هذا الخيار لن يفيدك في الإصدار 7.0 - من المخطط أن تختفي هذه الخيارات تمامًا.

إذا كنت تميل إلى "الانتظار حتى الإصدار 7.0" قبل إجراء أي تنظيف للإعدادات، فهذا فخ.الإصدار 6.0 RC هو الإصدار الذي من المفترض أن تقوم فيه بإصلاح مشكلتك tsconfigيجب توحيد أنواع البيانات، والتعامل مع العلامات المهملة. إن إجراء قفزتين كبيرتين (من الإصدار 5.x إلى 7.0) سيؤثر سلبًا بشكل أكبر من الانتقال من الإصدار 5.x إلى 6.0 ثم إلى 7.0 مع تغييرات أصغر وأكثر تحكمًا.

ما الذي تغير منذ الإصدار التجريبي 6.0

بين الإصدار التجريبي والإصدار النهائي، ركز فريق TypeScript بشكل أساسي على مواءمة السلوك مع محرك الإصدار 7.0 المستقبليبالإضافة إلى بعض التعديلات المستهدفة في فحص الأنواع وأنواع DOM.

يؤثر أحد التغييرات المهمة على التحقق من نوع تعبيرات الدوال التي يتم تمريرها إلى الاستدعاءات العامة.خاصةً في سياقات JSX. عند استدعاء الدوال العامة باستخدام ردود الاتصال (على سبيل المثال في React أو مكونات JSX الأخرى)، يُحسّن RC عملية الاستدلال ليعكس بدقة أكبر ما سيفعله الإصدار 7.0. عمليًا، قد تلاحظ أن بعض الاستدعاءات التي كانت تعتمد على الاستدلال الضمني تتطلب الآن وسيط نوع صريحًا لضمان سلامة التحقق من النوع، ولكنك ستكتشف أيضًا المزيد من الأخطاء الحقيقية في التعليمات البرمجية الحالية.

تم توسيع نطاق إهمال صيغة تأكيد الاستيراد أيضًاكانت لغة TypeScript تحذر بالفعل من القديم import ... assert {...} تغير بناء الجملة في عمليات الاستيراد الثابتة بسبب اقتراح ECMAScript بالتحول إلى سمات الاستيراد مع withوالآن، ينطبق هذا الإهمال أيضًا على عمليات الاستيراد الديناميكية باستخدام import() باستخدام كائنات التأكيد مثل import(..., { assert: {...}})الاتجاه واضح: الانتقال إلى استيراد السمات في كل مكان.

تم تحديث أنواع مكتبة DOM لتتوافق مع معايير منصة الويب الحاليةبما في ذلك تحديثات واجهات برمجة التطبيقات المتعلقة بـ Temporal في سياقات الويب. إذا كنت تقوم بتطوير تطبيقات متصفح، فستستفيد من دقة أكبر في تحديد أنواع البيانات وأدوات تحرير أفضل لهذه الواجهات البرمجية الأحدث.

حساسية أقل للسياق بالنسبة للوظائف التي لا تستخدم أبدًا this

يُدخل TypeScript 6.0 تغييرًا دقيقًا ولكنه عملي للغاية في كيفية تعامله مع الدوال التي لا تحتوي على تعريف صريح this الاستخدام أثناء استنتاج النوعتاريخياً، يمكن اعتبار الدوال ذات المعاملات التي تفتقر إلى أنواع صريحة "حساسة للسياق"، مما يعني أن معاملاتها و this تعتمد أنواع البيانات على مكان استخدامها. يؤثر ذلك على الاستدلال العام وقد يؤدي إلى سلوك غير متوقع اعتمادًا على بنية الدالة.

لنفترض وجود دالة مساعدة عامة تستخدم زوجًا من المنتج والمستهلك:

declare function callIt<T>(obj: {
  produce: (x: number) => T,
  consume: (y: T) => void,
}): void;

// Arrow functions: everything infers fine
callIt({
  produce: (x: number) => x * 2,
  consume: y => y.toFixed(),
});

// Flipped property order still fine with arrows
callIt({
  consume: y => y.toFixed(),
  produce: (x: number) => x * 2,
});

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

في الإصدار 6.0، وظائف لا تقرأ أبدًا this يتم التعامل معها الآن على أنها أقل حساسية للسياقوبعبارة أخرى، إذا رأى المترجم ذلك this إذا لم يُستخدم هذا الأسلوب داخل دالة، فلن يؤثر سلبًا على أداء تلك الدالة أثناء الاستدلال. هذا يعني أن صيغة الأسلوب وصيغة السهم أصبحتا أكثر اتساقًا في سيناريوهات الاستدلال العامة، كما اختفى السلوك الغريب المتمثل في "العمل بترتيب خصائص معين، والفشل بترتيب آخر" في هذه الحالات.

يُحسّن هذا التغيير من تحديد أولويات المرشحين لاستنتاج النوع: وظائف بدون استخدام this تصبح مصادر معلومات ذات أولوية أعلى عند استنتاج وسائط النوع مثل T. يصبح التأثير أقل غموضاً unknown أنواع واستدلال أكثر استقرارًا عبر عمليات إعادة الهيكلة. ساهم في هذا العمل ماتيوس بورزينسكي.

دعم Node #/ استيراد المسار الفرعي

تتيح ميزة "استيراد المسارات الفرعية" في Node للحزم تعريف أسماء مستعارة داخلية للاستيراد عبر imports مجال في package.jsonتُسهّل هذه الأسماء المستعارة عمليات الاستيراد بتجنب المسارات النسبية العميقة. سابقًا، كان يجب أن يحتوي كل مفتاح مسار فرعي على مقطع واحد على الأقل بعد المقطع الأولي. #، وهو قيد صغير ولكنه مزعج للأشخاص الذين اعتادوا على اتفاقيات التجميع مثل @/....

يدعم TypeScript 6.0 الآن استيراد المسارات الفرعية التي تبدأ بـ #/بما يتماشى مع سلوك Node 20 الأحدث. هذا يعني أنه يمكنك استخدام تكوين مثل:

{
  "name": "my-package",
  "type": "module",
  "imports": {
    "#": "./dist/index.js",
    "#/*": "./dist/*"
  }
}

باستخدام هذا الإعداد، يمكن للوحدات النمطية داخل الحزمة - وحتى المستهلكين - الاستيراد عبر موجز #/... بادئة بدلاً من المسارات النسبية الطويلة مثل ../../utils.jsيفهم TypeScript هذا النمط عندما --moduleResolution ومن المقرر أن node20, nodenext أو bundler، مما يعكس دلالات Node الحديثة. وقد تم تنفيذ هذا التحسين بواسطة المساهم magic-akari.

باستخدام --moduleResolution bundler مع --module commonjs

سابقا، --moduleResolution bundler لا يمكن استخدامه إلا مع --module esnext or preserveمع إهمال الطرازات القديمة node/node10 في وضع حل الوحدات النمطية، احتاجت العديد من المشاريع إلى مسار ترحيل يتناسب مع مخرجات CommonJS الحالية.

يسمح TypeScript 6.0 الآن بالدمج --moduleResolution bundler مع --module commonjsغالبًا ما يُمثل هذا المزيج خطوة عملية لقواعد البيانات التي لا تزال تستخدم CommonJS ولكنها تتجه نحو سير عمل يركز على أدوات التجميع أو منطق حل أحدث. ومن ثم، يمكن للمشاريع التخطيط لهجرة طويلة الأجل إلى أحد الخيارين التاليين:

• module: "preserve" مع moduleResolution: "bundler" بالنسبة لتطبيقات الويب المجمعة والإعدادات المماثلة، أو
• module: "nodenext" للبيئات التي تستهدف بشكل مباشر Node.js الحديثة.

يُعد هذا التغيير ذا أهمية خاصة بالنسبة للفرق المغادرة moduleResolution: node وراء لكننا لسنا مستعدين بعدُ لتبني مخرجات نظام إدارة الطوارئ بشكل كامل. فهو يوفر مساراً تدريجياً بدلاً من الانقطاع المفاجئ.

استخدم --stableTypeOrdering علامة لمحاكاة ترتيب الإصدار 7.0

من أبرز التحسينات المعمارية التي ستأتي في TypeScript 7.0 هي التحقق المتوازي من الأنواعتشغيل عدة مدققات بالتوازي يعني إمكانية زيارة أجزاء مختلفة من البرنامج بترتيبات مختلفة. إذا كانت معرّفات الأنواع وترتيب الرموز يعتمدان على ترتيب الزيارة، فقد ينتهي بك الأمر إلى ترتيب غير حتمي للاتحادات، وترتيب غير حتمي للخصائص، وحتى اختلافات نادرة في التشخيصات.

تُعيّن إصدارات TypeScript القديمة معرّفات الأنواع الداخلية بناءً على ترتيب المواجهة.تُستخدم هذه المعرّفات بعد ذلك لفرز عناصر مثل أنواع الاتحادات والخصائص. ولهذا السبب، فإن التعديلات التي تبدو غير ضارة - مثل إضافة عنصر جديد - قد تبدو غير ضارة. const قبل دالة موجودة - يمكن عكس ترتيب الاتحادات الحرفية في الناتج .d.ts الملفات، أو قم بتغيير طريقة طباعة بعض الأنواع في محرر النصوص الخاص بك.

ينتقل TypeScript 7.0 إلى ترتيب حتمي قائم على المحتوى للكائنات الداخليةيتم فرز كل نوع أو رمز وفقًا لبنيته، وليس وفقًا لترتيب زيارته العرضي، لذا سيُنتج البرنامج نفسه الترتيب نفسه باستمرار بغض النظر عن التوازي أو ترتيب الترجمة. وهذا يُزيل لغز "لماذا انقلب ترتيب الاتحاد فجأة؟".

لمساعدتك في مقارنة السلوك بين الإصدارين 6.0 و7.0، يقدم الإصدار التجريبي --stableTypeOrderingعند تفعيل هذا الخيار، يعتمد TypeScript 6.0 نفس خوارزمية ترتيب الأنواع الحتمية المستخدمة في الإصدار 7.0. والنتيجة هي تقليل الاختلافات بشكل كبير في ملفات تعريف الأنواع الناتجة، وزيادة قابلية التنبؤ بالمقارنات بين مخرجات الإصدارين 6.x و7.x.

لكن الحتمية ليست مجانية. التمكين --stableTypeOrdering قد يؤدي ذلك إلى إبطاء عملية التحقق من الأنواع بنسبة تصل إلى 25% تقريبًا، وذلك بحسب قاعدة التعليمات البرمجية الخاصة بك. وهو مصمم كأداة تشخيصية ومساعدة في عملية الترحيل، وليس كإعداد أداء دائم.

إذا كنت ترى أخطاء في النوع فقط عندما --stableTypeOrdering قيد التشغيليعني هذا عادةً أن الكود السابق كان يعتمد على الترتيب شبه العشوائي القديم للأنواع لكي يعمل الاستدلال بشكل صحيح. تتضمن الحلول عادةً جعل الأنواع صريحة - إضافة وسيط نوع إلى استدعاء عام إشكالي، أو إضافة تعليق توضيحي لمتغير بواجهة محددة بدلاً من الاعتماد كلياً على الاستدلال لكائن معقد.

جديد es2025 خيارات الهدف والمكتبة

يُضيف TypeScript 6.0 es2025 خيار لكلاهما target و libعلى الرغم من أن معيار ES2025 لا يُقدم بنية أساسية جديدة مقارنةً بالسنوات السابقة، إلا أنه يتضمن العديد من واجهات برمجة التطبيقات القياسية التي كانت سابقًا حكرًا على فئة معينة. esnext.

من خلال الاستهداف أو التضمين es2025ستحصل على أنواع محدثة للوظائف المدمجة الجديدة مثل RegExp.escapeوتم نقل بعض واجهات برمجة التطبيقات من esnext إلى es2025وهذا يشمل أشياء مثل Promise.try، ومساعدات التكرار، وإضافات Set أساليب وصلت إلى مرحلة النضج الكامل. ساهم في هذا العمل كينتا موريوتشي.

القصة الأوسع هي أن الوضع الافتراضي target يتتبع الإصدار 6.0 الآن سنة ECMAScript الحاليةوهذا ما يؤدي فعلياً إلى استخدام ES2025 عند عدم تحديد إصدار مستهدف. وهذا يتوافق بشكل أفضل مع واقع بيئات التشغيل الحديثة والأدوات المتطورة باستمرار.

أنواع مضمنة لواجهة برمجة التطبيقات الزمنية

وصل اقتراح "تمبورال" الذي طال انتظاره إلى المرحلة الثالثة، ومن المتوقع أن يحل محل الاقتراح سيئ السمعة Date واجهة برمجة تطبيقات للتعامل مع البيانات/الأوقات المعقدة. يوفر TypeScript 6.0 الآن أنواعًا من الدرجة الأولى لـ Temporal، لذا يمكنك البدء في كتابة التعليمات البرمجية المستندة إلى Temporal مع سلامة النوع الكاملة ودعم المحرر.

لتمكين الأنواع الزمنية، يمكنك استخدام --target esnext أو قم بتكوين مكتباتك بشكل صريح عن طريق شيء من هذا القبيل:

{
  "compilerOptions": {
    "lib": 
  }
}

أو يمكنك اختيار المجموعة الفرعية الزمنية فقط مع "esnext.temporal" إذا كنت ترغب في إعدادات أكثر دقة، فبمجرد تفعيلها، يمكنك كتابة التعليمات البرمجية على النحو التالي:

let yesterday = Temporal.Now.instant().subtract({
  hours: 24,
});

let tomorrow = Temporal.Now.instant().add({
  hours: 24,
});

console.log(`Yesterday: ${yesterday}`);
console.log(`Tomorrow: ${tomorrow}`);

يدعم بعض بيئات التشغيل خاصية Temporal، ويمكن إضافة دعم لها في بيئات أخرى.لذا، فإن هذه الأنواع قابلة للاستخدام فعليًا اليوم. ويجري حاليًا نشر التوثيق على موقع MDN (مع وجود بعض الثغرات التي لا تزال قيد الإنشاء). وقد ساهم مستخدم GitHub، Renegade334، في كتابة هذه الأنواع.

دعم التحديث والإضافة: Map.getOrInsert و getOrInsertComputed

يقوم مطورو جافا سكريبت بكتابة أنماط "التحقق ثم التعيين ثم الاسترداد" يدويًا على Map لسنوات. يقوم النمط النموذجي بالتحقق مما إذا كان المفتاح موجودًا، ويحدد قيمة افتراضية إذا لم يكن كذلك، ثم يُرجع قيمة في النهاية - وهو نمط نمطي يسهل ارتكاب الأخطاء فيه أو تكراره في كل مكان.

يقدم اقتراح "التحديث والإضافة" في ECMAScript (المرحلة الرابعة حاليًا) getOrInsert و getOrInsertComputed on Map و WeakMapيُضيف TypeScript 6.0 دعمًا للأنواع لهذه الطرق في esnext lib، لذا يمكنك البدء في كتابة عمليات إدراج وتحديث أكثر وضوحًا على الفور.

مع getOrInsertنمط مطول كهذا:

function processOptions(compilerOptions: Map<string, unknown>) {
  let strictValue: unknown;
  if (compilerOptions.has("strict")) {
    strictValue = compilerOptions.get("strict");
  } else {
    strictValue = true;
    compilerOptions.set("strict", strictValue);
  }
  // ...
}

يمكن طيها إلى سطر واحد:

function processOptions(compilerOptions: Map<string, unknown>) {
  let strictValue = compilerOptions.getOrInsert("strict", true);
  // ...
}

الرفيق getOrInsertComputed يُعدّ مثالياً لحالات التخلف عن السداد المكلفة—تتطلب هذه الدالة رد نداء لا يُستدعى إلا في حال غياب المفتاح. ويمكن لرد النداء هذا أن يستقبل المفتاح كمعامل، مما يسمح لك باستنتاج القيمة الافتراضية من المفتاح نفسه. وتُجسّد تعريفات TypeScript هذه السلوكيات بدقة، وذلك بفضل مساهمات Renegade334.

RegExp.escape وبناء تعبيرات منتظمة أكثر أمانًا

إذا سبق لك أن قمت بدمج سلاسل نصية مُدخلة من المستخدم في تعبير نمطي، فأنت تعلم أنه من المفترض أن تقوم بإلغاء الأحرف الخاصة أولاً.لكن معظم قواعد البيانات إما تعيد تنفيذ الهروب في دالة مساعدة أو تتجاهله تمامًا. يقترح مشروع RegExp Escaping (المرحلة الرابعة حاليًا) توحيد هذا الأمر باستخدام RegExp.escape.

يُتيح TypeScript 6.0 عرض أنواع لـ RegExp.escape تحت es2025 ليبوهذا يعني أنه عند استهداف أو تضمين ES2025، يمكنك كتابة دوال مساعدة بأمان مثل:

function matchWholeWord(word: string, text: string) {
  const escapedWord = RegExp.escape(word);
  const regex = new RegExp(`\\b${escapedWord}\\b`, "g");
  return text.match(regex);
}

لم تعد هناك حاجة إلى وظيفة هروب يدوية الصنعوسيفهم TypeScript واجهة برمجة التطبيقات (API) ويتحقق من أنواعها بشكل كامل. هذه الإضافة، مثل العمل على هدف ES2025، من ابتكار كينتا موريوتشي.

dom تتضمن المكتبة الآن واجهات برمجة تطبيقات للتكرار والتكرار غير المتزامن

تاريخيًا، قسمت لغة TypeScript دعم مُكرِّر DOM إلى dom, dom.iterableو dom.asynciterableإذا كنت ترغب في التكرار على NodeList or HTMLCollection مع for...ofكان عليك أن تتذكر أن تضيف dom.iterable في الخاص "lib" التكوين جنبًا إلى جنب domكان هذا مصدرًا شائعًا للارتباك، خاصةً وأن جميع المتصفحات الحديثة تدعم العناصر القابلة للتكرار والعناصر القابلة للتكرار غير المتزامنة في مجموعات DOM.

في TypeScript 6.0، lib.dom.iterable.d.ts و lib.dom.asynciterable.d.ts يتم دمجها فعلياً في lib.dom.d.ts. وهذا يعني استخدام "dom" يوفر لك الوضع الحالي وحده سلوكًا قابلاً للتكرار وغير متزامن بشكل افتراضي.

لا يزال بإمكانك ذكر ذلك dom.iterable و dom.asynciterable في الخاص tsconfigلكن هذه الملفات الآن عبارة عن ملفات فارغة. إذا كان تكوينك السابق يبدو كالتالي:

{
  "compilerOptions": {
    "lib": 
  }
}

يمكنك التبسيط بأمان إلى مجرد "dom"والتكرار على مجموعات DOM مثل document.querySelectorAll("div") سيتم التحقق من نوع النص:

for (const element of document.querySelectorAll("div")) {
  console.log(element.textContent);
}

هذا تنظيف صغير ولكنه مرحب به هذا يجعل مكتبة DOM الافتراضية متوافقة مع واقع المتصفحات الحالية ويزيل مشكلة أخرى من إعداد المشروع.

الإعدادات الافتراضية، والإلغاءات، والتغييرات الجذرية في TypeScript 6.0

إلى جانب واجهات برمجة التطبيقات البراقة، يُجري الإصدار 6.0 بعضًا من أكثر التغييرات جرأةً على الإعدادات الافتراضية لـ TypeScript منذ الإصدار 1.0.. تعكس هذه التغييرات النظام البيئي الحالي لـ JavaScript: أوقات التشغيل الدائمة، و ESM كأساس، والاستخدام الواسع النطاق لأدوات التجميع، والرغبة الشديدة في الكتابة الصارمة والأداء.

يسلط الفريق الضوء على بعض الاتجاهات العامة التي تدعم هذه القرارات: لقد اختفت تقريبًا ES5 والمتصفحات القديمة حقًا؛ أنظمة وحدات AMD/UMD متخصصة؛ يتم شحن كل شيء تقريبًا كوحدات الآن؛ الكتابة الصارمة هي القاعدة؛ ويجب أن يظل الأداء في المقدمة والمركز، خاصة مع جلب الإصدار 7.0 للتحقق المتوازي.

ونتيجة لذلك، يتم تشكيل TypeScript 6.0 و 7.0 بإعدادات افتراضية حديثة وعدد أقل من "صمامات الهروب القديمة".بالنسبة للإصدار التجريبي 6.0، يمكنك كتم إشعارات الإهمال مؤقتًا عن طريق ضبط "ignoreDeprecations": "6.0" في الخاص tsconfigلكن هذه الخيارات لن تكون متاحة في الإصدار 7.0. يمكن أتمتة بعض التعديلات باستخدام أدوات مثل الأداة التجريبية. ts5to6 codemod، الذي يمكن أن يساعد في إعادة كتابة أشياء مثل baseUrl و rootDir التكوينات عبر المشروع.

تعديلان ستحتاج إليهما العديد من المشاريع على الفور

على الرغم من وجود قائمة طويلة من التغييرات التي تم إيقاف استخدامها، إلا أن تغييرين في الإعدادات من المرجح أن يؤثرا على أكبر عدد من قواعد البيانات البرمجية.:

• حدد صراحةً types مجموعة (غالبا) بالإضافة إلى إطار الاختبار الخاص بك). بدون ذلك، ستفقد أنواع البيئة المضمنة تلقائيًا من @types/*.
• تم تحديده صراحةً rootDir (عادة "./src") إذا كنت تعتمد على "استنتاج الجذر المشترك" القديم. وإلا فقد يتغير هيكل الملف الناتج بطرق دقيقة.

أعراض الغياب types يتضمن ذلك سيلًا من الأخطاء المتعلقة بالمتغيرات العامة مثل process, fs, path أو describe غير محددأعراض التغير rootDir يتعلق الأمر أكثر بمسارات الإخراج التي تكتسب بشكل غير متوقع ميزة إضافية src مقطع (على سبيل المثال) dist/src/index.js بدلا من dist/index.js).

تم تحديث الإعدادات الافتراضية للمشاريع الحديثة

تتضمن العديد من خيارات المُصرّف الآن قيمًا افتراضية جديدة تتوافق مع كيفية بناء معظم التطبيقات الجديدة فعليًا.:

• strict أصبح الآن الوضع الافتراضي هو trueلم يعد الوضع الصارم خيارًا إضافيًا، بل أصبح الوضع الأساسي. إذا كنت تعتمد سابقًا على سلوك غير صارم، فسيتعين عليك تحديده بشكل صريح. "strict": false (مع ذلك، ستفوتك فئة كبيرة من فحوصات السلامة).
• module أصبح الآن الوضع الافتراضي هو esnext، مما يعكس أن ESM هو تنسيق الوحدة النمطية السائد ويعمل بشكل أفضل مع أدوات التجميع و Node الحديثة.
• target يتم استخدام إصدار ECMAScript الحالي افتراضيًا (وهو في الواقع ES2025 حاليًا).مع الإقرار بأن معظم عمليات النشر تستهدف بيئات دائمة التحديث أو تمر عبر أداة تجميع يمكنها الرجوع إلى مستوى أدنى عند الضرورة القصوى.
• noUncheckedSideEffectImports الآن true بشكل افتراضي، مما يساعدك على اكتشاف الأخطاء الإملائية أو المسارات الخاطئة في عمليات الاستيراد التي يتم تضمينها لأغراض التأثيرات الجانبية فقط.
• libReplacement التخلف عن false، مما يجنب مجموعة من عمليات حل الوحدات النمطية الفاشلة الإضافية وتكاليف المراقبة حتى يختار المشروع صراحةً سلوكيات المكتبة المتخصصة.

إذا تسبب أي من هذه الإعدادات الافتراضية الجديدة في تعطيل عملية البناء، فيمكن تجاوزها جميعًا بشكل صريح في tsconfig.jsonلكن الهدف هو أن تقوم المشاريع الجديدة "بالشيء الصحيح" دون الحاجة إلى تكوين إضافي.

rootDir يتم الآن استخدام دليل التكوين افتراضيًا

في السابق، إذا لم تحدد rootDirحاولت لغة TypeScript استنتاج جذر مصدر مشترك استنادًا إلى جميع الملفات غير التعريفية في البرنامج. وقد صعّب ذلك تحديد حدود المشروع، وتطلّب فحص مسارات ملفات عديدة لمجرد تحديد مكان تثبيت الأمر emit.

في TypeScript 6.0، الإعداد الافتراضي rootDir هو ببساطة الدليل الذي يحتوي tsconfig.jsonلا ينطبق سلوك الاستدلال القديم إلا عند تشغيل tsc على سطر الأوامر بدون أي tsconfig على الإطلاق.

هذا التغيير يعني أنه يجب على المشاريع التي تحتوي على ملفات مصدرية أعمق من دليل التكوين أن تحدد بشكل صريح rootDir. سيكون الإعداد الشائع كالتالي:

{
  "compilerOptions": {
    // ...
    "rootDir": "./src"
  },
  "include": 
}

إذا كانت إعداداتك تشير إلى ملفات أعلى من tsconfig الموقع، ستحتاج أيضًا إلى التمديد rootDir وفقا لذلك، على سبيل المثال "rootDir": "../src" للمجلدات المصدرية المشتركة.

types يتم الآن تعيينها افتراضيًا إلى مصفوفة فارغة

يمكن القول إن هذا هو التغيير الأكثر تأثيراً على المشاريع الواقعيةتاريخياً، إذا لم تحدد types in compilerOptions، سيقوم TypeScript تلقائيًا بتضمين كل شيء تحت node_modules/@typesكان ذلك مريحًا، ولكنه كان مكلفًا وهشًا أيضًا: غالبًا ما تستحوذ عمليات الاستحواذ الحديثة على مئات من @types بشكل متعدٍ.

في TypeScript 6.0، types التخلف عن []وهذا يعني أنه لا يتم تحميل أي حزم من نوع البيئة تلقائيًايمكنك الآن اختيار البيئات العالمية التي تحتاجها فعلياً بشكل صريح، على سبيل المثال:

{
  "compilerOptions": {
    "types": 
  }
}

يمكن أن يؤدي ذلك إلى تقليل أوقات البناء بنسبة تتراوح بين 20 و50% في بعض المشاريعلأن المترجم لم يعد مضطرًا إلى البحث في كل ملف تعريف تحت @typesإذا كنت ترغب حقًا في سلوك "تحميل كل شيء" القديم، فيمكنك تحديد ما يلي:

{
  "compilerOptions": {
    "types": 
  }
}

إذا ظهرت لك فجأة أخطاء مثل "لا يمكن العثور على الاسم 'process'" أو "لا يمكن العثور على الوحدة 'fs'"هذه هي فرصتك للإضافة node (وأي أنواع أخرى من الاختبارات/أوقات التشغيل التي تعتمد عليها) إلى types مجموعة مصفوفة.

إهمال: target: es5 و --downlevelIteration

أصبح استهداف ES5 الآن غير مدعوم.مع دعم جميع المتصفحات الحديثة لإصدارات ES2015 وما فوق لسنوات، وتوقف دعم Internet Explorer، لم يعد استخدام مخرجات ES5 يستحق التعقيد الذي يفرضه TypeScript نفسه. يُعد ES2015 هو الحد الأدنى للإصدارات المدعومة مستقبلاً. إذا كنت مُصراً على استخدام ES5، يُنصح باستخدام مُترجم خارجي (مثل Babel أو أداة تجميع) إما على كود TypeScript المصدر أو على مخرجاته.

استخدم --downlevelIteration تم إيقاف استخدام العلم أيضًا، لأن استخدامها الوحيد ذو المعنى كان تعديل سلوك الانبعاث لأهداف ES5. في TypeScript 6.0، يتم تعيين downlevelIteration سيؤدي استخدام هذا الخيار إلى ظهور خطأ يتعلق بالإهمال. إذا كنت تستخدم ES2015 أو إصدارًا أحدث، فلن يكون لهذا الخيار أي تأثير على أي حال.

إهمال: --moduleResolution node وإرث classic

استخدم node (الملقب node10وضع حل الوحدات النمطية مهمللقد حاكى هذا النظام سلوك Node 10، ولكنه لا يتوافق مع دلالات ESM و resolve في Node الحديثة. ينبغي على المشاريع الانتقال إلى أحد هذين النظامين. nodenext (للأهداف المباشرة للعقدة) أو bundler (للبيئات التي تعتمد على التجميع مثل تطبيقات الويب أو Bun).

الأصلي moduleResolution: classic تمت إزالة الاستراتيجية أيضًاكانت هذه هي قصة حل TypeScript قبل Node. أما اليوم، فإن جميع السيناريوهات العملية تُلبى بشكل أفضل بواسطة nodenext or bundlerلذلك تم الاستغناء عن الأسلوب الكلاسيكي لتقليل التعقيد والحالات الشاذة.

تم إيقاف استخدام: AMD، UMD، SystemJS، و module: none

ما يلي module أصبحت هذه القيم الآن مهملة وغير مدعومة فعلياً.:

• amd
• umd
• systemjs
• none

كانت هذه الصيغ بالغة الأهمية في حقبة ما قبل آلية الاستقرار الأوروبيعندما كانت المتصفحات تفتقر إلى دعم الوحدات النمطية الأصلي، وكان المطورون يعتمدون على AMD أو UMD أو SystemJS لسد هذه الثغرة. أما اليوم، فإن ESM بالإضافة إلى أدوات التجميع أو خرائط الاستيراد تعالج جميع حالات الاستخدام الحقيقية تقريبًا، ولم يكن مصطلح "لا شيء" محددًا بدقة.

إذا كنت لا تزال تستهدف تنسيقات الوحدات النمطية القديمة هذهالتوصية هي الانتقال إلى هدف يُصدر ملفات ESM والاعتماد على مُجمِّع أو مُترجم بديل للتغليف النهائي، أو البقاء على TypeScript 5.x حتى يتم وضع خطة انتقال. وكجزء من هذه العملية، سيتم استخدام الإصدار القديم amd-module تم إسقاط التوجيه أيضاً.

إهمال: baseUrl

استخدم baseUrl لطالما كان الخيار مصدرًا لسلوك غريب وصعب التصحيح في عملية حل الوحدات النمطيةاستخدمت العديد من المشاريع هذا المصطلح كبادئة فقط لـ paths إدخالات، لكن TypeScript تعامل معها أيضًا كجذر بحث عام، مما تسبب في عمليات استيراد مثل "someModule" أن يقرر src/someModule.js بشكل غير متوقع، بينما كان كل ما يقصده المطور هو دعم الأسماء المستعارة المخصصة مثل @app/*.

في 6.0، baseUrl تم إيقاف استخدامها ولن يتم استخدامها كجذر بحث بعد الآنلم يتطلب رسم خرائط المسار baseUrl لفترة طويلة، لذا فإن عملية الترحيل الموصى بها هي ببساطة دمج البادئة في كل paths مثال على المدخل:

// Before
{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": {
      "@app/*": ,
      "@lib/*": 
    }
  }
}

// After
{
  "compilerOptions": {
    "paths": {
      "@app/*": ,
      "@lib/*": 
    }
  }
}

فقط في حالات نادرة حيث استخدمت بالفعل baseUrl كجذر بحث عام هل ستحتاج إلى إعادة إنتاج هذا السلوك باستخدام تعيين مسار شامل مثل:

"paths": {
  "*": ,
  "@app/*": ,
  "@lib/*": 
}

بالنسبة لمعظم الفرق، يكفي ببساطة إزالة baseUrl وتضمين البادئات في paths سيكون الأمر أكثر وضوحاً وأماناً.

التوافق والصرامة: esModuleInterop, allowSyntheticDefaultImportsو alwaysStrict

يُثبّت TypeScript 6.0 أيضًا ما كان يُعتبر منذ فترة طويلة سلوك التوافق الافتراضي الموصى بهلم يعد بإمكانك ضبط esModuleInterop or allowSyntheticDefaultImports إلى falseكانت هذه الخيارات في الأصل اختيارية لتجنب تعطيل المشاريع القديمة، ولكن إيقاف تشغيلها اليوم يؤدي غالبًا إلى مشاكل دقيقة في وقت التشغيل عند دمج CommonJS و ESM.

مع تمكين خاصية التوافق دائمًا، قد يلزم تحديث بعض أنماط الاستيراد. على سبيل المثال:

// Old style with esModuleInterop: false
import * as express from "express";

// New style with modern interop always on
import express from "express";

استخدم alwaysStrict لا يمكن ضبط العلم أيضًا على false بعد الآنيفترض TypeScript الآن دلالات الوضع الصارم لـ JavaScript بشكل عام، بما في ذلك كيفية التعامل مع الكلمات المحجوزة و this تصرف بشكل لائق. إذا كان لديك كود قديم حقًا يستخدم كلمات محجوزة مثل await or static ستحتاج إلى إعادة تسميتها كمعرفات.

إهمال: outFileمساحة الاسم القديمة module الكلمة المفتاحية، والاستيراد asserts

استخدم --outFile تمت إزالة هذا الخيار في الإصدار 6.0يُعدّ دمج مدخلات متعددة في حزمة جافا سكريبت واحدة مهمةً يُفضّل أن تُنجزها أدوات مثل Webpack أو Rollup أو esbuild أو Vite أو Parcel أو ما شابهها. يركز TypeScript بشكل أكبر على التحقق من الأنواع وإصدار التصريحات بدلاً من محاولة أن يكون أداة تجميع.

الاستخدام التقليدي لـ module يُعدّ تعريف مساحات الأسماء الآن خطأً جسيماً.. كان مسموحًا باستخدام TypeScript في الإصدارات المبكرة:

module Foo {
  export const bar = 10;
}

يستخدم بناء الجملة الحديث والمدعوم namespace:

namespace Foo {
  export const bar = 10;
}

هذا التغيير ضروري لتجنب التعارض مع ECMAScript المستقبلي المحتمل module كتل. تعريفات الوحدات النمطية المحيطة مثل declare module "some-module" { ... } لا يزال يحظى بدعم كامل.

تأكيدات الاستيراد باستخدام asserts كما أنها مهملةلأن الاقتراح الأساسي تطور إلى سمات الاستيراد باستخدام with. كود مثل:

import blob from "./data.json" asserts { type: "json" };

ينبغي نقلها إلى النموذج الجديد:

import blob from "./data.json" with { type: "json" };

إهمال: no-default-lib المراجع وقوائم ملفات سطر الأوامر باستخدام tsconfig

استخدم /// <reference no-default-lib="true" /> لم يعد التوجيه مدعومًاكان يُساء فهمه في كثير من الأحيان. إذا كنت بحاجة إلى استبعاد المكتبة الافتراضية، فاستخدم --noLib or --libReplacement بدلاً من ذلك، والتي تعبر بشكل أوضح عن النية على مستوى التكوين.

ومن مصادر الارتباك الأخرى التي استمرت لفترة طويلة كيفية tsc يتعامل مع وسائط الملف الصريحة عندما يكون tsconfig.json حاضرسابقًا، الجري tsc foo.ts في مثل هذا المجلد، سيتم تجاهل ملف الإعدادات بصمت. أما في الإصدار 6.0، فينتج عن هذا السيناريو خطأ صريح:

error TS5112: tsconfig.json is present but will not be loaded if files are specified on commandline. Use '--ignoreConfig' to skip this error.

إذا كنت ترغب حقًا في تجاوز الإعدادات وتجميع ملف واحد فقط بالإعدادات الافتراضية، يمكنك الآن استخدام tsc --ignoreConfig foo.ts لتوضيح تلك النية.

الاستعداد لإصدار TypeScript 7.0

يُعد TypeScript 6.0 مكتمل الميزات وفي وضع الاستقرار في الغالبمن الآن وحتى الإطلاق العام، يتوقع الفريق إصلاحات للأخطاء الحرجة فقط. تُنشر الإصدارات التجريبية الليلية بانتظام، كما يُصدر الفريق أيضًا إصدارات تجريبية ليلية من TypeScript 7.0 الأصلي (المبني على Go) القادم، بالإضافة إلى إضافة مخصصة لبرنامج VS Code لتجربة المحرك الجديد.

تم وضع خطة زمنية محددة بدقة: من المتوقع أن يتبع الإصدار 7.0 الإصدار 6.0 بعد فترة وجيزة.لذا، ستكون فترة تلقي الملاحظات حول صعوبة الترقية ومشاكل الترحيل قصيرة. إذا كنت ترى تحذيرات بشأن إيقاف بعض الميزات في الإصدار 6.0، فننصح بشدة بمعالجتها الآن بدلاً من الانتظار حتى يُفرض الإصدار 7.0 هذه المشكلة.

تبدو آلية العمل العملية لمعظم الفرق على النحو التالي:قم بالترقية إلى TypeScript 6.0 RC، وقم بإصلاح مشكلتك types و rootDirمعالجة حالات الإهمال (أو حجبها مؤقتًا خلف "ignoreDeprecations": "6.0" أثناء التكرار)، والتشغيل مع --stableTypeOrdering إذا كنت بحاجة إلى مقارنة المخرجات أو إعداد مسارات التكامل المستمر (CI) لترتيب الإصدار 7.0 الحتمي. بمجرد إتمام ذلك، ستشعر أن الانتقال إلى المترجم المبني على لغة Go بمثابة تحسين للأداء وليس إعادة كتابة جذرية.

بشكل عام، لا يركز TypeScript 6.0 RC على بناء الجملة البراق بقدر ما يركز على تهيئة البيئة المناسبة.يتميز الإصدار 7.0 بسرعة فائقة، وإعدادات أكثر سلاسة، وإعدادات افتراضية حديثة، وواجهات برمجة تطبيقات موحدة مثل Temporal وES2025 المدمجة التي تُسهّل عملية البرمجة اليومية. إذا اعتمدته الآن، وقمت بإصلاح المشاكل التقنية، واعتمدت على الإعدادات الافتراضية الجديدة، فستكون في وضع أفضل بكثير عند إطلاق المُصرّف الأصلي.