كيف يعمل @ts-ignore لكتلة: 3 طرق في TypeScript

الصمت في المحرر: لماذا نحتاج إلى حظر TypeScript؟

كل من كتب بلغة TypeScript لمدة أسبوع على الأقل، واجه موقفًا يبدأ فيه المترجم في "الصراخ" على كود يبدو أنه يعمل. أنت متأكد من أن المنطق صحيح، لكن tsc أو بيئة التطوير المتكاملة (IDE) تبرز باللون الأحمر كل سطر ثانٍ. يكون الأمر مؤلمًا بشكل خاص عندما يحدث ذلك داخل كتلة واحدة: حلقة، شرط، أو دالة.

التعليق القياسي // @ts-ignore يعمل فقط مع السطر التالي. ماذا لو كنت بحاجة إلى "إسكات" المترجم لـ 10-15 سطرًا دفعة واحدة؟ نسخ نفس التعليق قبل كل سطر هو طريق مسدود. هذا لا يلوث الكود فحسب، بل يجعله أيضًا غير قابل للقراءة.

في هذه المقالة، سنستعرض ثلاث طرق عملية لتطبيق @ts-ignore لكتلة كاملة في TypeScript. ستتعرف على متى تكون كل منها مناسبة، ومتى يكون من الأفضل التخلي عن قمع الأخطاء تمامًا. هيا بنا!

المشكلة: @ts-ignore يعمل فقط على سطر واحد

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

// مثال: تحليل استجابة من API غير موثوق\nconst data: any = { user: { name: 'Alice', age: 30 } };\n\n// @ts-ignore\nconsole.log(data.user.name); // حسنًا، لكن سطر واحد فقط\n\n// السطر التالي سيسبب خطأ مرة أخرى إذا لم يتم إضافة // @ts-ignore\n// console.log(data.user.age); // خطأ: الخاصية 'age' غير موجودة في النوع 'object'\n

كتابة // @ts-ignore قبل كل سطر هي ممارسة سيئة. هذا يزيد من حجم الكود، ويعقد إعادة الهيكلة، ويخفي الأخطاء الحقيقية. لكن هناك أخبار سارة: TypeScript (بدءًا من الإصدار 3.9) والمجتمع طوروا عدة حلول أنيقة.

الطريقة 1: @ts-nocheck — القوة الغاشمة لملف كامل

أبسط طريقة، ولكنها الأكثر جذرية، هي إضافة // @ts-nocheck في بداية الملف. هذا يعطل التحقق من الأنواع بالكامل للملف بأكمله. لكننا نحتاج إلى كتلة، وليس ملفًا كاملاً. ومع ذلك، هناك حيلة: يمكنك نقل الكتلة الإشكالية إلى ملف منفصل واستيرادها.

الإيجابيات:

\n
• يحل المشكلة فورًا.
\n
• مناسب للكود القديم (legacy) الذي تخطط لإعادة كتابته لاحقًا.
\n

السلبيات:

\n
• يعطل جميع فحوصات الأنواع في الملف. قد تفوتك أخطاء حقيقية.
\n
• غير مناسب للمشاريع الكبيرة ذات قواعد التحقق الصارمة (linting).
\n
• يخلق "صناديق سوداء" من الكود.
\n

// bad.ts — ملف مع تعطيل التحقق\n// @ts-nocheck\nexport function processData(data: any) {\n    const result = data.user.name + ' is ' + data.user.age;\n    return result; // لن يكون هناك خطأ، حتى لو كانت data تساوي null\n}\n

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

الطريقة 2: ts-expect-error — البديل الذكي لـ @ts-ignore

بدءًا من TypeScript 3.9، ظهرت التوجيهية // @ts-expect-error. تعمل تقريبًا مثل @ts-ignore، ولكن مع فرق مهم: إذا لم يكن هناك خطأ، سيصدر TypeScript تحذيرًا. هذا يساعد في عدم نسيان إزالة التعليق بعد إصلاح الكود.

ولكن كيف نطبق هذا على كتلة؟ الإجابة — ليس بشكل مباشر. @ts-expect-error يعمل أيضًا على سطر واحد فقط. ومع ذلك، يمكننا استخدام حيلة مع دالة يتم استدعاؤها فورًا (IIFE).

// الكتلة التي يجب تجاهلها، ملفوفة في IIFE\n(function() {\n    // @ts-expect-error — نتوقع خطأ في السطر التالي\n    const x: number = 'hello'; // خطأ: النوع 'string' غير قابل للتخصيص للنوع 'number'\n\n    // @ts-expect-error — خطأ متوقع آخر\n    con