تحتاج هذا لول

حالة الاستخدام الحالية لهذه الميزة هي اختبار وحدة يتعامل مع المسافة البيضاء. تم تفعيل قاعدة "no-trailing-whites space" في قاعدة الشفرة لسبب وجيه ، ولكن عدم القدرة على التغلب عليها على مستوى الكتلة يعني أنه لا يمكننا اختبار مسافات بيضاء لاحقة وعودة أول السطر باستخدام سلسلة نموذج ES6 .

إحدى حالات الاستخدام الخاصة بي لاستخدام التجميع المخصص _ a.k.a partial import _ في الرياضيات

// tslint:disable:no-var-requires
import core from 'mathjs/core'

// @ts-ignore
import mathUnit from 'mathjs/lib/type/unit'
// @ts-ignore
import mathExpression from 'mathjs/lib/expression/function'
// @ts-ignore
import mathArithmatic from 'mathjs/lib/function/arithmetic'


const math = core.create()
// math.import(require('mathjs/lib/type/unit'))
// math.import(require('mathjs/lib/expression/function')) // compile, eval
// math.import(require('mathjs/lib/function/arithmetic')) // basic arithmetic like divide, exponent, etc

math.import(mathUnit)
math.import(mathExpression) // compile, eval
math.import(mathArithmatic) // basic arithmetic like divide, exponent, etc

export const unit = math.unit
export const createUnit = math.createUnit
export const compile = math.compile

أود تجاهل الأخطاء لملف كامل. لقد ورثت بعض رموز ES6 JS التي أود تحويلها إلى ES5 ولكن لا بد لي من استخدام Babel في الوقت الحالي. سيكون من الجيد فقط إعادة تسمية الملف إلى .ts و transpile مع TS.

ptallett يمكنك فقط تجميع ملفات .js باستخدام allowJs وتضمينها في التجميع. بشكل افتراضي ، لا نصدر أخطاء في ملفات .js ما لم يكن الملف يحتوي على تعليق // @ts-check في الأعلى ، أو قمت بتشغيل checkJs .

ما زلت أحب هذه الوظيفة ، فأنا أجلس في ملف اختبار ، وله الامتداد .ts ، لذلك يمكنني الاستيراد ورؤية المعلمات بسهولة إلى أين ، وتجميعها إلى دليل بجانب ملفات src أمر رائع لحالة الاستخدام الخاصة بي .

أصبحت معظم سطور الآن حمراء ، حيث أحاول عن قصد استبعاد بعض المعلمات ، أو إعطاء نوع مختلف للوظيفة ، عما تتطلبه في الأصل ، وأتوقع حدوث خطأ ، حيث أتحقق من ذلك في وقت التشغيل أيضًا.

سيكون من الجميل ألا يكون لديك مجموعة من الخطوط الحمراء في كل مكان. :)

هل هناك أي تحديث له ، أو هل وجد أي شخص طريقة جيدة للقيام بذلك؟

يعد استخدام lodash وخاصة lodash/fp مع TypeScript أمرًا مؤلمًا للغاية ، وحتى مع أحدث إصدارات lodash & @types/lodash يمكن أن ينتهي بك الأمر برسائل خطأ مشفرة للغاية.

إذا كان بإمكاننا الحصول على @ts-ignore-block يتجاهل أخطاء الكتلة التالية ، فسيكون ذلك رائعًا لحالات استخدام مثل هذه حيث _ أنت تعرف ما تفعله_ :-)

أنا أعمل مع رمز قديم مع العديد من المتغيرات العالمية المحددة ، وأصبحت كتابة @ ts-ignore في كل سطر مملة ، فهل توجد أية تحديثات على هذا؟

تسعى أيضا للحصول على تحديث لهذا الطلب. شكرا!

سيكون هذا أيضًا مهمًا جدًا لما أفعله (أي وظائف عرض قالب Vue التي تم إنشاؤها من خلال فحص النوع ، والتي تتطلب تعطيل عمليات فحص محددة لكتلة من التعليمات البرمجية.)
إلى جانب هذه المشكلة ، سيكون # 19139 مهمًا للغاية ، لأنه خاصة عند التقديم على أجزاء كبيرة من التعليمات البرمجية ، سترغب فقط في تعطيل عمليات فحص محددة.

مع قمع ملف الفتحة ، يمكن إضافة هذا إلى المحررين مثل vs code لحفظه في إعدادات مساحة العمل أو ما شابه.

تحتاج هذا أيضا. أقوم بإنشاء ملف ts كاملًا تلقائيًا بأنواع مخطط GraphQL الخاص بي باستخدام graphql-code-generator وهناك استيراد غريب يؤدي إلى noUnusedLocals.

/ * tslint: تعطيل * /

الشفرة

/ * tslint: تمكين * /

// @ts-ignore-start
// @ts-ignore-end

يمكن دمجه مع: https://github.com/Microsoft/TypeScript/issues/19139

// @ts-ignore-start Property_0_does_not_exist_on_type_1
// @ts-ignore-end (possible include the error type again so you can turn be more specific of where you want to ignore some errors

marianturchyn هذا ليس tslint.

في بعض الأحيان ، بينما أقوم بنقل الأشياء وإعادة البناء ، أرغب في تجاهل الملف بالكامل مؤقتًا (أي عدم تجميعه) ، دون العبث بخيارات CLI.

الأسرع / الأسهل هو وضع علامة أعلى الملف:

// @ts-ignore-file

@ lonix1 يتم تغطية حالة الاستخدام بواسطة:

// @ts-ignore-start
// @ts-ignore-end

ليس عليك استخدام الجزء // @ts-ignore-end . تعمل العديد من أدوات الوبر بهذه الطريقة.

mgol لا أريد إخراج هذا الموضوع عن مساره ... لكنني جربت اقتراحك - شكرًا! - ولم ينجح معي. لقد جمعت الأسطر معًا في أعلى الملف ، وجربت أيضًا أحدهما في الأعلى والآخر في الأسفل.
هل يمكن لأي شخص آخر الحصول عليها للعمل؟

@ lonix1 قصدت أن اقتراح Blanen سيعمل أيضًا من أجلك ، ولسنا بحاجة إلى TypeScript لتنفيذ كلاً من // @ts-ignore-start + // @ts-ignore-end و // @ts-ignore-file ، تنفيذ // @ts-ignore-start سيكون // @ts-ignore-end كافيًا. لم يتم تنفيذ هذا ، ولهذا السبب لا تزال هذه القضية مفتوحة.

DanielRosenwasser لن يعمل هذا إلا عند تخزين ملفات ts في مجلد آخر أثناء الإنشاء. عندما يتم إعداد المشروع لوضع ملفات js بجوار ملفات ts التي لن يفعلها. هل سيتم أيضًا "تجميع" ملفات js ، على سبيل المثال التحويل إلى es5؟ عند نقل الكود القديم سيكون هذا مفيدًا حقًا.

تحتاج هذه الميزة.

حالة الاستخدام:

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

@Entity('investigation')
export class InvestigationEntity {
    @PrimaryGeneratedColumn('uuid')
    // @ts-ignore TS2564
    public investigationId: string;

    @Column({ type: 'uuid' })
    // @ts-ignore TS2564
    public userId: string;

    @Column({ type: 'jsonb' })
    // @ts-ignore TS2564
    public metadata: IEncryptedJSONContainer;
}

كل عمود مطلوب ومن المؤكد أنه يحتوي على قيمة ، ولكن نظرًا للطريقة التي يعمل بها TypeORM ، يجب تعريف كل خاصية بطريقة تفتقر إلى المُهيئ. سيكون من الملائم للغاية أن تكون قادرًا على قمع هذه المشكلة المحددة المشتقة من ORM / لفصل كامل (وبالتالي / أو ملف).

haggholm هل من سبب لتفضيل ts-ignore على public metadata!: IEncryptedJSONContainer ؟

تضمين التغريدة لقد فاتني هذه الميزة في الوثائق. آسف؛ تجاهل من فضلك.

أود أن أفعل

// @ ts-ignore-start
- الشيكات الفارغة لملف واحد

هذا هو ما لا يجرؤ على الحقول الخاصة والأساليب ذات المظهر المطبوع. لدي 6 أسطر مخصصة لتجاهل التعليمات البرمجية. سيى. يجعل عيني تنزف. سيكون موضع تقدير كبير أي حلول بديلة لتجاهل الكتلة.

it('TestNode_ReconnectionsWorkload', async function () {
    for (let i = 0; i < 1; i++) {
        nodes.push(await Node.NewNode(serverUrl, {
            handlers: {
                active: async function (n: Node) {
                    try {
                        // @ts-ignore
                        if (n.view.Empty()) {
                            // @ts-ignore
                            if (n.conns.Empty() && !n.server) {
                                // @ts-ignore
                                await n.login(n.address);
                            }
                            return;
                        }

                        const data = new flats.Message({
                            // @ts-ignore
                            id: n.id,
                            type: flats.MessageType.Data,
                            data: 'hello world',
                        });

                        const dataBytes = data.toBytes();
                        const dataBase64 = base64.encode(dataBytes);
                        // @ts-ignore
                        const dataSigBytes = await n.sign(dataBytes);
                        const dataSigBase64 = base64.encode(dataSigBytes);

                        // @ts-ignore
                        for (const conn of n.conns.Iter()) {
                            conn.Send(`${dataBase64}.${dataSigBase64}`);
                        }
                    } catch (error) {
                        console.log(error);
                    }
                },
            },
        }));
    }

    for (const node of nodes) {
        await node.Wait();
    }
});

حسنًا ، كنت على وشك إضافة عدد جديد ، لكن أعتقد أن هذه المشكلة تغطيها.

@ ts-ignore يتعامل مع واردات متعددة الأسطر وسطر واحد مختلفة!

لا يزال هناك الكثير من وحدات npm التي لا تحتوي على كتابات ، أو تمت كتابتها بدون NoImplicitAny ،
والتي ينتج عنها خطأ "ضمنيًا" ثم يتم استيرادها:

import { a, b } from 'MyNonTypedModule' // <-- Implicit any error

لذا يمكنني استخدام @ ts-ignore:

//@ts-ignore
import { a, b } from 'MyNonTypedModule'

ولكن عندما أعمل مع الاستيراد التلقائي والمنسقات مثل Prettier ، يحدث هذا:
(تنسيقه أجمل)

//@ts-ignore
import { 
  a, 
  b 
} from 'MyNonTypedModule' // <-- Still (again) getting the Implicit any error

يمكنني إصلاحه بـ:

import { 
 a, 
 b
//@ts-ignore
 } from 'MyNonTypedModule'

أو

//@ts-ignore-start
import { 
   a, 
   b
} from 'MyNonTypedModule'
//@ts-ignore-end

ولكن بعد ذلك تبدأ في الظهور على النحو التالي في عمليات الاستيراد التي يتم استيرادها من سطر واحد:

//@ts-ignore-start
import { a } from 'MyNonTypedModule'
//@ts-ignore-end
import { b } from 'SomeTypedModule'
//@ts-ignore-start
import { c } from 'SomeOtherNonTypedModule'
//@ts-ignore-end

لذلك يجب أن أكتبها على هذا النحو لأن الاستيراد التلقائي والتنسيق سيتغيران بين الاستيراد أحادي السطر ومتعدد الأسطر اعتمادًا على عدد العناصر التي يتم استيرادها من الوحدة النمطية.
إنه يتعارض حقًا مع الغرض من الاستيراد التلقائي إذا كان لدي تغيير رمز الاستيراد يدويًا.

سيكون من الجيد ألا تضطر إلى كتابة ts-ignore-start و ts-ignore-end في كل عملية استيراد مفردة ،
لذا: // @ ts-ignore للاستيراد (وليس السطر التالي فقط) هو في رأيي شيء يجب أن يتجاهله ts-ignore. (أو تجاهل البعض الآخر مثل: @ ts-ignore-block / @ ts-ignore-import)

أحتاج إلى منع بعض الأخطاء في الملف بأكمله:

// @ts-ignore-all TS1206

/*
... rest of the file
*/

بالاتفاق مع الأشخاص أعلاه الذين اقترحوا تعليقات // @ts-ignore-start و // @ts-ignore-end للتعامل مع حالات الاستخدام المذكورة في هذا الموضوع.

هذا جميل ، لأنه يبدو مشابهًا جدًا للتوجيه الحالي // @ts-ignore ، ويسمح لك بتجاهل جميع الأخطاء في ملف باستخدام التوجيه // @ts-ignore-start فقط في الأعلى.

هناك حالات استخدام إيجابية لعدد من الاقتراحات المذكورة أعلاه. انا اقترح:

السلوك الحالي هو @ts-ignore
@ts-ignore TSxxx [TSxxx ...] منع أخطاء معينة
حظر @ts-ignore-start بدء التجاهل
@ts-ignore-start TSxxx [TSxxx ...] بإيقاف خطأ (أخطاء) معين للحظر
كتلة @ts-ignore-end end
@ts-ignore-all يمنع الأخطاء لبقية الملف
يقوم @ts-ignore-all TSxxx [TSxxx ...] بإيقاف خطأ (أخطاء) معين لبقية الملف

يمكن أن تتضمن "أخطاء محددة" مجموعات مسماة مماثلة لتلك الموجودة في tsconfig أو المجموعات المعرفة من قبل المستخدم لأخطاء TSxxx.

لست متأكدًا من قيمة تجاهل الكتل التي تتداخل مع الوحدات المستوردة ؛ أفضلي سيكون صريحًا كتل ts-ignore داخل ملفات الوحدة النمطية المستوردة. ولكن عند استيراد libs من جهة خارجية ، قد تكون هناك أسباب لذلك ، لذا فأنا على الحياد هنا.

مطلوب ملف .tsignore

تمامًا مثل .npmignore & .gitignore

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

// @ts-ignore-start
// @ts-ignore-end

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

حول

// @ts-ignore-start
// @ts-ignore-end

لقد قدمت هذا الاقتراح في وقت سابق وأريد نوعًا ما تغيير بناء الجملة.
اجعله يبدأ - توقف أو يبدأ - النهاية
start و end (كأفعال) ليسا متضادات وهذا من شأنه أن يزعجني إلى الأبد إذا دخل في الكتابة المطبوعة.

هذا رائع معي

// @ts-ignore-begin
// @ts-ignore-end

الوظائف المطلوبة بشدة.

لماذا لا يزال هذا غير ممكن؟ :-(

أحتاج إلى تجاهل الحظر أيضًا

+1

+1

أي تحديث على هذا؟

🙏🏻

وإذا فعلنا ذلك بنفس الطريقة التي نفعلها عادةً مع eslint؟

/* @ts-disable */

!function(){
  // no ts here!
}()

/* @ts-enable */

كما هو مذكور أعلاه: بمجرد قيامك بإنشاء رمز TS (على سبيل المثال مع swagger) حيث قد تحدث متغيرات غير مستخدمة على سبيل المثال ، فأنت بحاجة إلى هذه الميزة.

+1

بدون //@ts-ignore-file يستحيل الترحيل إلى TS

لذلك ، فمن دون أن يلاحظ أي شخص هذا غير صحيح

RyanCavanaugh من الواضح أن المجتمع بحاجة إلى ذلك ، فهل هناك سبب لعدم معالجة ذلك؟ شكرا!

أنا أعاني من هذا في الوقت الحالي حيث لا يمكنني حتى أن أجد صعوبة في الحصول على حل يعمل لمعرفة ما إذا كان ذلك ممكنًا حتى دون أن تبكي شركة "تنك سكريبت" وتحظر تصيير.

نحن حاليا بحاجة لهذه الميزة.

نحن نستورد مكتبة عامة بها أنواع عقدة لبعض الوظائف التي لا نهتم بها. لذا سيكون من الجيد استخدام // @ ts-ignore لاستيراد واحد ، بدلاً من استخدام skipLibCheck للتجاهل كل الليب.

في البداية أحببت // @ ts-ignore-file idea ، لكن // @ ts-ignore ربما تعمل بشكل أفضل من أجل الاتساق.

لذلك .... فتحت رقم 33383 بدعم //@ts-nocheck في ملفات نصية. الآن ، نظرًا لكوننا فريق مترجم _TypeScript_ ، فإننا لا نحصل عليه حقًا ، لأنفسنا (لم نصلح المشكلات المحتملة ، whaaaat !!؟!؟) - حتى //@ts-ignore في الكتابة المطبوعة أصبح شيئًا فقط لأن ذراعنا كانت ملتوية قليلاً ، لذلك نحن ... مترددون ... في إضافة آليات قمع أخرى. لذا ، إذا شعرت حقًا أن آلية القمع الواسعة هذه مطلوبة ، فسيكون من الجيد أن تذهب هناك و

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

نظرًا لأن هذه المشكلة لا تزال تحمل التصنيف "في انتظار المزيد من التعليقات" ، فإليك المزيد:

عند وضع نماذج أولية لاتجاهات معمارية جديدة بسرعة ، أود أن أفعل ذلك مسترشدًا بـ TypeScript ، للتأكد من أن الهيكل الجديد سيعمل. ومع ذلك ، أريد أن أتجاهل مؤقتًا أخطاء الكتابة في ملفات اختبار الوحدة ، مؤقتًا فقط ، أثناء التجربة.

إضافة نوع من التعليقات @ts-ignore- في الجزء العلوي من كل ملف سيكون أمرًا سهلاً بما فيه الكفاية.

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

weswigham يمكنك وضعه خلف علم مترجم.

يمكنك وضعه خلف علم المترجم.

لا حاجة - إنه في الإصدار التجريبي 3.7.

إعادة: https://github.com/microsoft/TypeScript/pull/33383:weswigham هذا رائع ، شكرًا! هناك حالة استخدام قوية هنا تتمثل في تجاهل نوع التحقق في ملف مؤقتًا ، لذا أقترح أيضًا شحن قاعدة النسالة التي تفشل عندما ينسى المرء إزالة @ts-nocheck

وجود مشكلة في gatsby ، حيث يعمل استعلام GraphQL الثابت في ملفات .jsx ، لكن ليس في ملفات .tsx . أعتقد أن هذا الاقتراح يمكن أن يكون حلًا أكثر قابلية للتأكيد. (الإصدار هنا https://github.com/AdamLeBlanc/gatsby-plugin-ts-loader/issues/5)

يا!
هل تم تنفيذ الحل المقترح؟

// @ ts-ignore-start
// @ ts-ignore-end

أعتقد أنه سيكون مفيدًا للغاية. لا أمانع في العمل عليها.

أضفنا دعمًا لـ //@ts-nocheck لمنع جميع الأخطاء في ملف كامل في الإصدار 3.7. أعتقد أن قمع مستوى الخط والملف يمكن أن يشمل _ معظم_ الاحتياجات دون الكثير من الجلبة. إذا كان لديك كتلة كبيرة بما فيه الكفاية داخل ملف محدد يجب إلغاء تحديده ، فربما تقوم فقط بتعطيل التحقق من الملف بالكامل أو ، إذا كان ذلك مقيتًا ، قم باستخراج الجزء الذي لم يتم التحقق منه إلى ملفه الخاص وتعطيل التحقق من هذا الملف ، أو في حالة فشل ذلك ، قمع كل سطر مع قضية فعلية؟ من المفترض أن يتجاهل A ts-ignore مشكلة واحدة ، بينما من المفترض أن يتجاهل ts-nocheck ملفًا واحدًا - فالقمع المستند إلى النطاق لا يتم تعيينه فعليًا إلى وحدة معينة بأي شكل من الأشكال ، لذلك يبدو أسوأ إلى حد ما (لأنه لا يمكن تعيينه لمشكلة واحدة أو سبب جذري تقوم بقمعه). على الأقل بدون عمليات قمع خاصة برمز الخطأ ، لست مرتاحًا بشكل خاص للقمع المستند إلى النطاق.

أنا ، على الأقل ، أفضل قمعًا واحدًا ( //@ts-nocheck File is a legacy untyped UMD module concatenated into the build - declarations are pulled from node_modules, so errors here are hopefully meaningless ) في الجزء العلوي من الملف أو قمع فردي ( //@ts-ignore The TS compiler doesn't support the assignment on the next line because we never declare it, but we provide this for legacy compat ) لكل شيء سيء فردي (tm). لا يمكنني ، طوال حياتي ، أن أتوصل إلى مثال مقنع ومبدئي حيث يجب السماح بإلغاء تحديد درجات معينة من التعليمات البرمجية (على عكس الملفات ، التي تحتوي على تفكير واضح مدعوم بإستراتيجية الهجرة) ، بخلاف "الكتابة المتعددة المتتالية عمليات القمع تجعل عيني تنزف "، وهو الأمر الذي أتعاطف معه ، لأنه ، بشكل أساسي ، نعتقد أنه لا ينبغي لك استخدام أدوات القمع في TypeScript على الإطلاق. إذا كانت مشكلة تتعلق بالنوع ، فيمكنك التخلص منها (وهذا هو سبب وجود إعلانات وحدة الإرسال والاختزال any ). إذا كانت مشكلة في بناء الجملة ، فكل شيء سيء وسننهار على أي حال ، لذا لن تفعل عمليات الكتم أي شيء (لا تؤثر عمليات القمع على أخطاء التحليل).

شكرًا على //@ts-nocheck ، لكن هذا لا يحل مشكلة تعطيل التحقق من حظر الرمز:

const $element = document.createElement('iframe')
$element.loading = 'lazy' // Property 'loading' does not exist on type 'HTMLIFrameElement'.

// @ts-nocheck

لدي حالة استخدام مثيرة للاهتمام.

لقد قمنا ببناء أو امتلاك ORM في Typescript الذي يستخدم البلوط لتجميع العبارات في DDL الخاص بنا.

لإجراء استعلام حيث يتعين علينا تمرير متغيرات النطاق:

.entities
.include('parent')
.where(m => m.id === this.id, { id: this.entityId })
.toList()

هذا لا يعمل لمجرد: Property 'id' does not exist on type 'xxx'

إذا قمت بلفه بـ @ts-ignore-start فسوف يعمل بشكل جيد مثل هذا:

// @ts-ignore-start
.where(m => m.id === this.id, { id: this.entityId })
// @ts-ignore-end

ولكن عندما يأتي التنسيق ويبدأ في إضافة فواصل الأسطر:

// @ts-ignore-start
.where(m => m.id === this.id || m.id === this.id2, {
  id: this.entityId,
  id2: this.entity2Id
})
// @ts-ignore-end

لم يعد يعمل.

هذا لا يعمل ببساطة للأسباب التالية:

هذا هو بالضبط نوع الخطأ على مستوى النوع الذي يجب أن يكون لديك فقط as any cast (أو ، في jsdoc ، /** <strong i="8">@type</strong> {any} */(expr) ) على حق الوصول ، إذا كنت تريد حقًا قمعه.

//@ts-nocheck لا يصلح لمشروعي ts الزاوي ولكن //@ts-ignore يعمل. بدأت هذه المشكلة لـ Microsoft في عام 2017. 2017! رائع...

3 سنوات الآن ولا يوجد حل. ليس من المستغرب أن لا يرغب مطورو JavaScript في الانتقال إلى الكتابة المطبوعة

// @ts-ignore-start
// @ts-ignore-end

يمكن دمجه مع: # 19139

// @ts-ignore-start Property_0_does_not_exist_on_type_1
// @ts-ignore-end (possible include the error type again so you can turn be more specific of where you want to ignore some errors

marianturchyn هذا ليس tslint.

أي خطط لتنفيذ هذا؟

// @ts-nocheck
هو الخيار الوحيد حاليا :(

حالة استخدام أخرى لإضافتها للنظر هنا ...

أنا أقوم بتوليد مجموعة من كود TypeScript من لغة ترميز داخلية تسمح ببعض تدفق التحكم الأساسي والشروط الشرطية. بينما أتحكم في سلوك إنشاء الكود ، لا أتحكم في المدخلات التي تم تمريرها إلى منشئ الكود (الأمر متروك للمستخدمين النهائيين)

نتيجة لذلك ، قد يكون للشفرة التي تم إنشاؤها رمز لا يمكن الوصول إليه بسهولة ، أو في حالة واحدة TS2367 حيث قد يكون هناك رمز متداخل يختبر قيمة مقابل ثابت التعداد ، ثم يحتوي داخل تلك الكتلة على فحص آخر لهذا المتغير مقابل ثابت تعداد آخر. علي سبيل المثال:

if (foo === MyEnum.ONE) {
  const bar = (foo === MyEnum.TWO ? "two" : "one");
}

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

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

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

هل أنت جاد؟ لا تزال هذه مشكلة مفتوحة ولم يتم تنفيذها في TS4؟ 🤦🏽

ivnnv يمكنك استخدام // @ts-expect-error في TS 3.9 ، انظر هنا

يعملndraiman @ts-expect-error للخطوط الفردية ولكن ليس للكتل ، لذلك لا يزال هناك حاجة لوضع العديد منها إذا أراد المرء "تجاهل كتلة"

إليك المزيد من التعليقات لك:

ماذا تريد ايضا؟ ما الذي يتعين على المجتمع القيام به للحصول على هذه الوظيفة؟

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

تختلف وجهات نظر الناس حول ما هو مقبول وما هو غير مقبول.

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

مثال:

أحدهما هو نقل مشروع من JS إلى TS ، بينما يتم تطوير المشروع الآخر بواسطة طرف ثالث.

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

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

سيكون من الرائع التوقف عن فحص وظيفة أو جزء من التعليمات البرمجية في ملف أثناء إصلاحه. إن تجاهل كتلة الكود سيمكن المرء من التحرك بسرعة في المناطق التي يعرفها والتي يشعر بالراحة معها وحفظ أجزاء معينة في وقت لاحق.

سير العمل الخاص بي عندما يتعين عليّ نقل JavaScript إلى TypeScript (والشفرة ، حسناً ، subpar):

1. انسخ الكود من .js إلى ملف .ts.
2. تحقق مما إذا كان بإمكان TS الاستدلال على أي أنواع من خلال الاستخدام
3. فهم الأنواع يدويًا من الاستخدام
4. أدرك أن الأخطاء هي لعنة وجودي
5. حاول التعليق على الأخطاء ، وبالتالي تحسين عدد الأسطر في الملف أحيانًا x3 ESLlint + TS (هل المزيد أفضل؟)
6. قم بإزالة وإضافة // @ts-check في الجزء العلوي مع تحرير باقي الملفات بعناية وإضافة المزيد من الأنواع.

إذا تمكنا من تجاهل الكتل:

1. انسخ الرمز من .js إلى .ts
2. تحقق مما إذا كان بإمكان TS الاستدلال على أي أنواع من خلال الاستخدام
3. فهم الأنواع يدويًا من الاستخدام
4. // @ts-ignore-enable ... // @ts-ignore-disable وظائف فردية وكتل التعليمات البرمجية المزعجة
5. كتل Uncomment عندما أحصل عليها وأضيف أنواعًا

قرر بنفسك ما يبدو أكثر منطقية. إنه نفس الشيء عند نقل JS إلى مشروع مع المزيد من قواعد ESLint ، وعليك إعادة بناء معظم الأشياء.

أتمنى أن نفعل ما هو ممكن في ESLint واستخدام /* eslint:disable */ ... /* eslint:enable */ في TypeScript.

ملاحظة: لقد أدركت للتو عند التحقق من هذا التعليق أنني أمضيت 20 دقيقة + في محاولة الحصول على تجربة كنت أبحث عنها (والعديد من الآخرين) منذ عام 2017 ، فقط للتعليق على قضية مفتوحة عمرها 3 سنوات.

تضمين التغريدة

تذكير: +1:

سيعطي بكر في مقابل هذا

agusterodin تضحيتك تلفت انتباه الشرور .....

حسنًا ، لا يحدث شيء في الواقع ، إلا أنني أعطي فقط علاقات عامة بسيطة :)

ومع ذلك ، أنا شخصياً أتفق بشدة مع رأي فريق TS - هذه الوظيفة شريرة ، يجب أن تحاول دائمًا تجنب استخدام @ts-ignore ، وليس استخدام @ts-ignore-enable (أو @ts-ignore-start ، ما من أي وقت مضى).
لكن في بعض الأحيان ، كما تعلمون ، يقول المثل drinking posion to satisfie thirst ، أعلم أنه اختيار سيء ، لكنه فقط في حاجة.

تحرير: إضافة شرح والأمثلة.
يضيف هذا العلاقات العامة توجيهين ts-ignore-enable و ts-ignore-disable .

1. في حالة استخدام ts-ignore-enable فقط ، فسيتم تجاهل الجزء الباقي.

...   <-- this is normal
// @ts-ignore-enable
XXX    <-- this is ignored
...    <-- this is ignored

1. يمكنك إضافة نفس التوجيهات لمرات عديدة ، لكنها تعمل لمرة واحدة فقط.

// @ts-ignore-enable
XXX  <-- this is ignored  
// @ts-ignore-enable       <-- you could remove this line.
YYY   <-- this is ignored
// @ts-ignore-disable
ZZZ   <-- this is normal
// @ts-ignore-disable      <-- you could remove this line.

1. يمكن استخدام // @ts-ignore-disable بمفرده ، ولن يحدث شيء.

2. @ts-expect-error لن يعمل في المنطقة التي تم تجاهلها

// @ts-ignore-enable
XXX  <-- this is ignored
// @ts-expect-error       <-- No error message. whatever next line has error or not.
YYY   <-- this is ignored

1. لا توجد تسمية المنطقة ، هم مجرد تعليق.

// @ts-ignore-enable A
XXX  <-- this is ignored  
// @ts-ignore-enable   B    <-- you could remove this line.
YYY   <-- this is ignored 
// @ts-ignore-disable B
ZZZ   <-- this is normal
// @ts-ignore-disable A     <-- you could remove this line.

في عالم مثالي ، لن نحتاج إلى تجاهل نوع الأمان ، أليس كذلك؟ : sweat_smile:
أحتاجه عند نسخ عمل رائع ، على سبيل المثال ، أمثلة ومبتدئين ، حتى إجابة SO العرضية التي لم تتم كتابتها أو كتابتها كما أريد. في الغالب للحصول عليه في رمز النوع الآمن الخاص بي الذي يتبع إعداداتي. أنا فقط أستخدم إعدادات صارمة للغاية وغالبًا ما أضطر إلى إعادة كتابة دالة أو بعض المنطق بسبب ذلك. ليس لأنني أرغب في الاستمرار في تجاهل كتلة التعليمات البرمجية ، فلن يكون ذلك منطقيًا.

يعد تجاهل كتلة من التعليمات البرمجية أمرًا مريحًا بالنسبة لي ، ويبدو أنه معقول تمامًا نظرًا لحقيقة أنه لا يزال بإمكاني @ts-ignore كل سطر في الكتلة.

أتفهم التداعيات المحتملة التي قد تترتب على الأشخاص الذين يتجهون إلى I'll just ignore this because it's easier . كما أراها ، أي شخص يمكنه استخدام نطاق الكتلة يتجاهل drink poison to satisfy their thirst يشرب بالفعل قطرات من السم مع @ts-ignore .

الآن بعد أن أصبح بإمكانك عمل ملفات @ts-nocheck في ملفات .ts ، أقترح السماح بملفات @ts-check في ملفات .ts أيضًا حتى نتمكن من إيقاف / تشغيل مدقق النوع:

import fs from 'fs'

fs.readFileSync(32423) // type checking

// @ts-nocheck
fs.foobarbaz() // type checking is off
fs.__randomThing()

// @ts-check
fs.readFileSync(123) // now type checking again

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

تحديث كنت مخطئا ، راجع https://github.com/microsoft/TypeScript/pull/40267#issuecomment -713840095 للتصحيح.

عند محاولة ترحيل تطبيق باستخدام styled-components إلى TypeScript ، واجهت مشكلة حيث لا يمكن استخدام @ts-ignore أعلى سلاسل القوالب (لسبب ما). كان من الممكن حلها باستخدام حظر التجاهل.

مثال على خطأ TS كنت أحاول تجاهله:

import styled from "styled-components";
import { Button } from "...";

// @ts-ignore here does not work
const StyledNavBar = styled.div`
  ${Button} {
    margin: auto 0;
  }
`;

كملاحظة إضافية: لا يمكنني إلقاء أي شيء في مشروع TS الخاص بي ، ولا أسمح بأي أنواع. ما هي التوصية إذن؟

weswigham ما هي أفكارك حول حالة التدفق والإنتاجية في سياق الجماليات؟ يبدو أنه ليس لديك أي تعاطف مع نزيف العيون. ولكن هل لديك أي مفاهيم حول الإنتاجية ورمز النقل والعمليات التي وصفتها؟ هل ما زلت لا ترى أي فائدة - على الإطلاق - بعد النظر في تعليقي ، وفي سياق كونك أكثر إنتاجية؟ لقد وصفت أيضًا بعض المواقف الحقيقية التي يحتاج فيها المرء إلى تجاهل نطاق الكتلة. علاوة على ذلك ، كيف لا تقارن هذه الوظيفة بـ ESLint والوظائف التي نتوقعها هناك؟

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

بالنسبة لي ، يبدو أنك تتجه نحو المدينة الفاضلة بينما تتجاهل الواقع. sandersn لم تتناول أيًا من نقاطي واحتفظ بالرد القديم على المناقشات الأحدث في القضية. أنت تذكر أيضًا أنه ما لم يقرر الفريق خلاف ذلك ، فلا يجب تنفيذه ، وفي هذه الحالة: أغلق المشكلة؟

يحتاج الفريق إما إلى اتخاذ قرار أو تنفيذ ميزة مطلوبة بوضوح.

إبقاء القضية في طي النسيان لا معنى له.

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

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

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

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

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

لا يزال يبدو أنه لم يتم إحراز أي تقدم فعلي تجاه قضية ذات أكثر من 700 رد فعل إيجابي ، أي منذ عدة سنوات. لا أعتقد أنه يجب أن يتم ذلك بشكل أسرع ، ولكن يبدو أن الفريق غير مهتم باستكشاف هذه الميزة لأن الأعضاء لديهم آراء شخصية ضدها. أنا أفهم تمامًا كل هذه الأشياء. هذا ليس ما أنا عليه هنا ، رغم ذلك. أريد أن أستمر في الحديث ، لكن يتم تجاهلي.

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

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

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

لقد قدمت عدة حجج ضد نقاط weswigham ، وقدمت بعض الأمثلة ، وما زلت بصراحة في انتظار نوع من الرد عليها. الشيء الوحيد الذي بدا أنه يساعد في ذلك هو الشعور بالضيق وعدم البناء.

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

أود أن أكرر أنني أفهم أن هذا قد لا يكون أولوية عالية إذا أخذنا آراء الناس بعيدًا عن الموضوع. في الوقت نفسه ، تكون الميزة جاهزة للتنفيذ ، وقد تم تقديم الحجج. ما نحتاجه الآن هو أن يتخذ الفريق قرارًا / استجابة (وليس بالضرورة تنفيذ أي شيء) ونشره على الملأ. إذا لم يكن هذا هو المطلوب ، فيرجى إخباري بما هو مطلوب ، أو كيف يمكن للمرء أن يساعد في زيادة الأولوية على أي ميزة أو مشكلة لـ TypeScript ، ولكن بشكل خاص هذه الميزة.

حالة استخدام أخرى لخطوط متعددة ( @ts-ignore-start+@ts-ignore-end ) أو مضمنة (مثل /* @ts-ignore */ ) @ts-ignore .
بيئة:

• "noUnusedParameters": true
• تمكين قاعدة ESLint require-jsdoc .
• كود مشابه لما يلي (مثال مبسط):

type Data = Record<string, unknown>;
type PrepareSettings = Record<string, unknown>;

/**
 * This is base class that will be inherited.
 */
class SuperClass {
    /**
     * Prepare data for further usage.
     * 
     * <strong i="16">@param</strong> data
     *      Data that should be prepared.
     * <strong i="17">@param</strong> settings
     *      Operation settings.
     */
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {
        return data;
    }

    // Some additional methods...
}

بالنسبة للموقف الموصوف ، يصدر TypeScript التحذير التالي: 'settings' is declared but its value is never read.(6133) .
من الممكن منع التحذير بإضافة @ts-ignore بعد نهاية تعليق التوثيق:

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {

ولكن بعد ذلك سوف يشتكي ESLint من Missing JSDoc comment .
إذن الحل هو:

     */   // @ts-ignore
    prepareData(data: Data, settings: PrepareSettings): Data | undefined {   // eslint-disable-line require-jsdoc

وهو أمر محرج وقبيح.

تضمين التغريدة _

تذكير شهري بأن هذا شيء يريد المجتمع مناقشته أكثر مع فريق TypeScript. هناك الكثير من الدعم وما ينقص حاليًا هو استجابة من الفريق. لقد أدركت أن هناك الكثير من الراجحة ، والتقدم في TypeScript ليس بالأمر السهل. الأمور تستغرق وقتا. نظرًا لعدم وجود رد بخصوص كيفية تعزيز هذا الاقتراح واتخاذ المزيد من الإجراءات المباشرة ، سأقوم بتذكير مثل هذا بانتظام. لن أستسلم حتى يتم اتخاذ قرار ، ويبدو أن التعليق يؤثر (غالبًا عندما تكون! @ # رغم ذلك).

بعد مرور هذه السنوات ، على الرغم من أنني كنت في الأصل منزعجًا من عدم وجود هذه الوظيفة ، فقد أعدت التفكير فيها شخصيًا قليلاً ... عندما يكون هناك مجموعة ضخمة من @ts-ignore ، قد تخبر بالفعل أن هناك شيئًا خاطئًا مع شفرتك ، واقضِ بعض الوقت في تحسين أنواعك. نحن جميعًا كسالى جدًا في بعض الأحيان ، ونريد السرعة بشكل عام ، ولكن غالبًا ما يكون من الأسهل حاليًا اكتشاف بعض الأنواع المناسبة بدلاً من نسخ ولصق عدة @ts-ignore في مجموعات كبيرة من التعليمات البرمجية. إذا تم كسر هذا التوازن في عدم الراحة ، فسيقوم الكثير منا بإساءة استخدام @ ts-ignore-enable بشكل ملائم ، مما قد يؤدي فقط إلى تقليل الجودة الإجمالية لجميع المشاريع الصغيرة مفتوحة المصدر هنا وهناك.

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

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

قم بإزالة وظيفة @ts-ignore أو اجعلها كاملة. هناك العديد من الحجج للقيام بذلك ، وسيستمر الأشخاص الذين يكتبون رمزًا سيئًا في استخدام @ts-ignore وهو أمر سيئ مثل ميزة تجاهل الكتلة ، فهم نفس الشيء تمامًا - باستثناء تجاهل الحظر لأنه أقل إزعاجًا بصريًا.

لا يزال المجتمع بحاجة إلى استجابة من فريق TypeScript.

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

قم بإزالة وظيفة @ts-ignore أو اجعلها كاملة. هناك العديد من الحجج للقيام بذلك ، وسيستمر الأشخاص الذين يكتبون رمزًا سيئًا في استخدام @ts-ignore وهو أمر سيئ مثل ميزة تجاهل الكتلة ، فهم نفس الشيء تمامًا - باستثناء تجاهل الحظر لأنه أقل إزعاجًا بصريًا.

لا يزال المجتمع بحاجة إلى استجابة من فريق TypeScript.

لا تزال بعض السيناريوهات الخاصة بحاجة إلى استخدام تجاهل @ TS. على سبيل المثال ، لا يعتمد استيراد CDN على node_ The. ملف TS غير موجود في سيناريو الوحدات النمطية

@ L-Hknu شكرا للتوضيح. يستخدمه الناس لأنهم يستخدمون التجاهلات مع ESLint على أي حال.

وظيفة التجاهل غير مسموح بها في السياقات إلى جانب الأماكن التي تحتاج إليها للوظيفة. هذا يخبرني أنه لا بأس من استخدامه لتجاهل الكود.

ما زلت لا أستطيع تفسير سبب عدم وجود تجاهل للكتلة ، حيث يتم استخدامه بنفس الطريقة في معظم الأوقات.

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

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

@ L-Hknu شكرا للتوضيح. يستخدمه الناس لأنهم يستخدمون التجاهلات مع ESLint على أي حال.

وظيفة التجاهل غير مسموح بها في السياقات إلى جانب الأماكن التي تحتاج إليها للوظيفة. هذا يخبرني أنه لا بأس من استخدامه لتجاهل الكود.

ما زلت لا أستطيع تفسير سبب عدم وجود تجاهل للكتلة ، حيث يتم استخدامه بنفس الطريقة في معظم الأوقات.

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

يبدو أنه انتهى
# 40267