مقالة مختصرة عن أسباب عدم قيام Node.js بتطبيق TypeScript.

أول الأشياء أولا

ما يلي هو شرح لما وما لم يتم القيام به في Node.js فيما يتعلق بـ TypeScript.

ليس المقصود من هذه المقالة أن تكون انتقادًا لفريق Node.js أو فريق TypeScript.

في الواقع، الأمر عكس ذلك تمامًا.

أعتقد جديًا أن فريق Node.js قد اتخذ أفضل خيار ممكن في "تنفيذ" TypeScript بالطريقة التي فعلوها.

ما أؤكده هنا هو أن Node.js لم يقم بتنفيذ TypeScript. لقد أضافوا للتو نوعًا من الدعم لها. وهذا تمييز مهم أعتقد أنه غالبًا ما يتم التغاضي عنه في المناقشات حول Node.js وTypeScript.

في الأسبوعين الماضيين، أحصيت أكثر من 50 مقالة تم الاستشهاد بها في النشرات الإخبارية التي قرأتها والتي ذكرت أن Node.js قامت بتنفيذ TypeScript.

أعتقد أن الوقت قد حان لتوضيح هذه النقطة مرة واحدة وإلى الأبد.

تنبيه حرق معلومات: Node.js لم يقم بتنفيذ TypeScript.

TypeScript: تاريخ موجز وبعض البيانات

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

وفقًا لأحدث استطلاع لحالة JS، فإن TypeScript موجود عمليًا في كل مكان. 78% من المطورين يستخدمون TypeScript لما لا يقل عن 50% من وقت التطوير، لذلك لا عجب أن صدى "Node.js نفذت TypeScript" وصل حتى إلى أعمق أركان الويب.

ولكن، فقط للتوضيح، لم يحدث ذلك. وربما لن يحدث ذلك أبدًا.

القضايا

هناك عدة أسباب لعدم قيام Node.js بتنفيذ TypeScript. إليك ما أعتقد أنهما أهم شيئين:

#1: يقوم TypeScript بإدخال الأشياء في وقت التشغيل.

هل تعلم ما الذي يصبح عليه التعداد في وقت التشغيل؟ كائن.

وهذا مجرد واحد من الأمثلة القليلة - لحسن الحظ - لكيفية إدخال TypeScript للأشياء في وقت التشغيل. هذه مشكلة بالنسبة لـ Node.js لأنها تعني أن وقت التشغيل يجب أن يكون على دراية بميزات TypeScript، الأمر الذي قد يؤدي إلى الكثير من التعقيد والنفقات العامة.

إذا أراد Node.js الحفاظ على اتساقه مع ECMAScript وعدم الاضطرار إلى التعامل مع إدارة التبعيات لبقية وجوده، فلا يمكنه قبول TypeScript باعتباره تبعية في النموذج الحالي.

#2: الإصدار الدلالي.

لا يتبع TypeScript الإصدارات الدلالية (semver).

من ناحية أخرى، يتبع Node.js semver بشكل صارم ولديه ثلاثة خطوط إصدار مختلفة (حاليًا، لدينا 18.x، 20.x، 22.x). وهذا يعني أنه يمكن إدخال تغييرات جذرية في الإصدارات الثانوية أو التصحيحية، مما قد يسبب مشكلات في التوافق مع التعليمات البرمجية الموجودة.

كما أن عدد الأنظمة الأساسية المدعومة ضخم، لذا ليس من السهل التحقق من كل شيء.

لا يمكن لـ Node.js ببساطة قبول TypeScript باعتباره تبعية لأنه قد يؤدي إلى انقطاع الخدمة. هذه مشكلة أساسية تمنع Node.js من تنفيذ TypeScript.

فماذا فعلوا؟

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

هل تريد مثال؟ ها أنت ذا:

function sum(a: number, b: number): number {
  return a   b;
}

هذه الوظيفة، عند تجميعها باستخدام علامة --experimental-strip-types، ستصبح:

function sum(a        , b        )         {
  return a   b;
}

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

داخليًا، يتم ذلك عبر حزمة تسمى أمارو والتي تغلف swc - وهي أداة بناء معروفة تقوم بالتجريد الفعلي.

بالطبع، توجد قيود، مثل عدم القدرة على استخدام الميزات الخاصة بـ TypeScript مثل التعدادات المذكورة مسبقًا. ولكن لا يزال منع الأشخاص من كتابة 135 ملف تكوين لجعل دالة الجمع تقبل رقمين وترجع رقمًا ثالثًا خطوة كبيرة إلى الأمام.

مايكل.