इस लोल की जरूरत है

इस सुविधा के लिए वर्तमान उपयोग मामला एक इकाई परीक्षण है जो व्हाइटस्पेस से संबंधित है। हमारे पास अच्छे कारण के लिए हमारे कोडबेस में "नो-ट्रेलिंग-व्हाट्सएप" नियम चालू है, लेकिन ब्लॉक स्तर पर इसे प्रबल करने में सक्षम नहीं होने का मतलब है कि हम ईएस 6 टेम्पलेट स्ट्रिंग का उपयोग करके पिछली व्हाइटस्पेस और कैरिज रिटर्न के लिए आसानी से परीक्षण नहीं कर सकते हैं। .

गणित में कस्टम बंडलिंग _ 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 में ट्रांसपाइल करना चाहता हूं लेकिन इस समय बैबेल का उपयोग करना है। फ़ाइल का नाम बदलकर .ts करना और TS के साथ ट्रांसपाइल करना अच्छा होगा।

@ptallett आप allowJs का उपयोग करके allowJs .js फ़ाइलों को संकलित कर सकते हैं और इसे संकलन में शामिल कर सकते हैं। डिफ़ॉल्ट रूप से, हम .js फ़ाइलों में त्रुटियाँ तब तक जारी नहीं करते जब तक कि फ़ाइल के शीर्ष पर // @ts-check टिप्पणी न हो, या आप checkJs चालू न करें।

मैं अभी भी इस कार्यक्षमता को पसंद करूंगा, मैं एक परीक्षण फ़ाइल में बैठा हूं, इसका विस्तार .ts है, इसलिए मैं आयात कर सकता हूं और आसानी से देख सकता हूं कि कौन से पैरामीटर कहां जाते हैं, और इसे src फ़ाइलों के बगल में एक निर्देशिका में संकलित करना मेरे उपयोग के मामले के लिए शानदार है। .

मेरी अधिकांश पंक्तियाँ अब लाल हैं, क्योंकि मैं उद्देश्य से कुछ मापदंडों को बाहर करने की कोशिश करता हूं, या फ़ंक्शन को एक अलग प्रकार देता हूं, जो मूल रूप से लेता है, और एक त्रुटि की उम्मीद करता है, जैसा कि मैं इसे रनटाइम में भी जांचता हूं।

हर जगह लाल रेखाओं का गुच्छा न हो तो अच्छा होगा। :)

क्या इस पर कोई अपडेट है, या किसी को ऐसा करने का कोई अच्छा तरीका मिला है?

टाइपस्क्रिप्ट के साथ lodash और विशेष रूप से lodash/fp का उपयोग करना बहुत दर्दनाक है, और यहां तक ​​कि lodash और @types/lodash के नवीनतम संस्करणों के साथ भी आप बहुत ही गुप्त त्रुटि संदेशों के साथ समाप्त हो सकते हैं।

अगर हमारे पास एक @ts-ignore-block हो सकता है जो निम्नलिखित ब्लॉक के लिए त्रुटियों को अनदेखा करता है, तो इस तरह के मामलों का उपयोग करने के लिए यह बहुत अच्छा होगा जहां _आप जानते हैं कि आप क्या कर रहे हैं_ :-)

मैं कई वैश्विक दायरे वाले चर के साथ विरासत कोड के साथ काम कर रहा हूं, और प्रत्येक पंक्ति पर @ ts-ignore लिखना कठिन हो गया है, इस पर कोई अपडेट?

साथ ही इस अनुरोध पर अपडेट मांग रहे हैं। धन्यवाद!

मैं जो कर रहा हूं उसके लिए यह भी बहुत महत्वपूर्ण होगा (अर्थात् टाइप-चेकिंग जेनरेट किए गए वीयू टेम्पलेट रेंडर फ़ंक्शंस, जिसके लिए कोड के ब्लॉक के लिए विशिष्ट निरीक्षण अक्षम करने की आवश्यकता होगी।)
इस मुद्दे के साथ, #19139 बहुत महत्वपूर्ण होगा, क्योंकि विशेष रूप से कोड के बड़े हिस्से पर आवेदन करते समय, आप केवल विशिष्ट निरीक्षणों को अक्षम करना चाहेंगे।

छेद फ़ाइल को दबाने के साथ इसे वर्कस्पेस सेटिंग्स या ऐसे में सहेजने के लिए बनाम कोड जैसे संपादकों में जोड़ा जा सकता है।

इसकी भी जरूरत है। मैं 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 नहीं है।

कभी-कभी जब मैं सामान को इधर-उधर कर रहा होता हूं और रिफैक्टरिंग करता हूं, तो मैं अस्थायी रूप से पूरी फाइल को अनदेखा करना चाहता हूं (यानी इसे संकलित नहीं करना), बिना सीएलआई विकल्पों के साथ खिलवाड़ किए।

फ़ाइल के शीर्ष पर एक ध्वज सबसे तेज़/आसान है:

// @ts-ignore-file

@ lonix1 आप केस का उपयोग करते हैं:

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

आपको // @ts-ignore-end भाग का उपयोग करने की आवश्यकता नहीं है। कई लिंट टूल इस तरह से काम करते हैं।

@mgol मैं इस धागे को पटरी से नहीं उतारना चाहता ... लेकिन मैंने आपके सुझाव की कोशिश की - धन्यवाद! - और यह मेरे लिए काम नहीं किया। मैंने फ़ाइल के शीर्ष पर पंक्तियों को एक साथ रखा, और एक को सबसे ऊपर और दूसरे को नीचे की ओर भी आज़माया।
क्या कोई और इसे काम पर ला सकता है?

@ lonix1 मेरा मतलब था कि @Blanen का प्रस्ताव आपके लिए भी काम करेगा, हमें // @ts-ignore-start + // @ts-ignore-end और // @ts-ignore-file दोनों को लागू करने के लिए टाइपस्क्रिप्ट की आवश्यकता नहीं है, // @ts-ignore-start को लागू करना // @ts-ignore-end पर्याप्त होगा। इसे लागू नहीं किया गया है, इसलिए यह मुद्दा अभी भी खुला है।

@DanielRosenwasser यह तभी काम करेगा जब ts फाइलें बिल्ड के दौरान किसी अन्य फोल्डर में स्टोर हो जाएंगी। जब प्रोजेक्ट जेएस फाइलों को टीएस फाइलों के बगल में रखने के लिए सेटअप किया जाता है तो यह नहीं होगा। जेएस फाइलों को भी 'संकलित' किया जाएगा जैसे ईएस 5 में बदलना? विरासत कोड परिवहन करते समय यह वास्तव में सहायक होगा।

इस सुविधा की जरूरत है।

उदाहरण:

टाइपओआरएम हमें डीबी इकाई वर्ग बनाने की उम्मीद करता है जिसमें कॉलम होते हैं जो शून्य हो सकते हैं या नहीं भी हो सकते हैं। कई कॉलम (इसलिए) अशक्त नहीं हैं ... और इसलिए वर्ग परिभाषा को छोड़कर , व्यवहार किया जाना चाहिए, जैसे कि गुण कुछ निश्चित प्रकार के बिना शर्त हैं। हालाँकि, टाइपस्क्रिप्ट के लिए हमें प्रत्येक कॉलम को दृढ़ता से टाइप किए जाने के रूप में परिभाषित करने की आवश्यकता होती है। इसलिए, हम बहुत सारी संस्थाओं के साथ समाप्त होते हैं जैसे:

@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;
}

प्रत्येक कॉलम की आवश्यकता होती है और (इसलिए) निश्चित रूप से एक मूल्य होता है, लेकिन टाइपओआरएम के काम करने के तरीके के कारण, प्रत्येक संपत्ति को इस तरह से परिभाषित किया जाना चाहिए कि इसमें प्रारंभकर्ता की कमी हो। पूरी कक्षा (इसलिए/या फ़ाइल) के लिए इस विशेष, ओआरएम-व्युत्पन्न/विशिष्ट मुद्दे को दबाने में सक्षम होना बेहद सुविधाजनक होगा।

@haggholm ts-ignore से अधिक public metadata!: IEncryptedJSONContainer पसंद करने का कोई कारण?

@RyanCavanaugh अज्ञानता! मैंने दस्तावेज़ीकरण में उस सुविधा को याद किया था। माफ़ करना; कृपया उपेक्षा कर दीजिये।

मैं करना पसंद करूँगा

// @ ts-अनदेखा-शुरू
--strick नल चेक, एक विशेष फ़ाइल के लिए

यह वही है जो निजी क्षेत्रों और टाइपस्क्रिप्ट के तरीकों को एकजुट करता है। मेरे पास कोड को अनदेखा करने के लिए समर्पित 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-अनदेखा का उपयोग कर सकता हूं:

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

लेकिन जब मैं ऑटो आयात और प्रीटीयर जैसे फॉर्मेटर्स के साथ काम करता हूं तो ऐसा होता है:
(सुंदर द्वारा स्वरूपित)

//@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- आयात के लिए अनदेखा करें (केवल अगली पंक्ति नहीं) मेरी राय में कुछ ऐसा है जिसे 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 अंत ब्लॉक
@ts-ignore-all शेष फ़ाइल के लिए त्रुटियों को रोकें
@ts-ignore-all TSxxx [TSxxx ...] शेष फ़ाइल के लिए विशिष्ट त्रुटि (त्रुटियों) को दबाएं

"विशिष्ट त्रुटियों" में tsconfig या TSxxx त्रुटियों के उपयोगकर्ता-परिभाषित समूहों के समान नामित समूह शामिल हो सकते हैं।

मैं आयातित मॉड्यूल को नेस्टिंग ब्लॉकों की उपेक्षा के मूल्य के बारे में निश्चित नहीं हूँ; मेरी वरीयता आयातित मॉड्यूल फ़ाइलों के भीतर ts-अनदेखा ब्लॉक को स्पष्ट करेगी। लेकिन तीसरे पक्ष के libs आयात करते समय इसके कारण हो सकते हैं इसलिए मैं यहां बाड़ पर हूं।

.tsignore फ़ाइल चाहता था

जैसे .npmignore और .gitignore

इग्नोर ब्लॉक होना चाहिए। मैं कठपुतली ढांचे के साथ फंस गया। कठपुतली में आपने "मूल्यांकन" विधि की है जो आपको किसी पृष्ठ पर मनमानी स्क्रिप्ट ब्लॉक चलाने की अनुमति देती है। इस मनमानी स्क्रिप्ट ब्लॉक में उन कार्यों का संदर्भ हो सकता है जो पृष्ठ पर उपलब्ध हैं, दूसरे शब्दों में फ़ंक्शन संदर्भ रनटाइम पर उपलब्ध होगा।

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

विरासत कोड के टुकड़ों के साथ काम करते समय यह बेहद आसान होगा, जिससे लोगों को टाइपस्क्रिप्ट पर स्विच करना कम दर्दनाक हो जाएगा।

के बारे में

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

मैंने यह सुझाव पहले दिया था और वाक्य रचना को बदलना चाहता हूं।
या तो इसे स्टार्ट-स्टॉप बनाएं या स्टार्ट-एंड
start और end (क्रिया के रूप में) विलोम नहीं हैं और अगर यह टाइपस्क्रिप्ट में आ गया तो यह मुझे हमेशा के लिए परेशान करेगा।

यह मेरे साथ अच्छा है

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

अत्यधिक आवश्यक कार्यक्षमता।

यह अभी भी संभव क्यों नहीं है? :-(

मुझे ब्लॉक इग्नोर भी चाहिए

+1

+1

इस पर किसी भी अद्यतन?

🙏🏻

और अगर हम इसे वैसे ही करते हैं जैसे हम आमतौर पर एस्लिंट के साथ करते हैं?

/* @ts-disable */

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

/* @ts-enable */

जैसा कि ऊपर उल्लेख किया गया है: जैसे ही आप टीएस कोड उत्पन्न कर रहे हैं (उदाहरण के लिए स्वैगर के साथ) जहां अप्रयुक्त संस्करण हो सकते हैं, आपको इस सुविधा की आवश्यकता है।

+1

//@ts-ignore-file के बिना TS . में माइग्रेट करना असंभव है

तो, यह बिना किसी की सूचना के सच नहीं है

@RyanCavanaugh समुदाय को स्पष्ट रूप से इसकी आवश्यकता है, क्या कोई कारण है कि इसे संबोधित नहीं किया गया है? धन्यवाद!

मैं अभी इसके साथ संघर्ष कर रहा हूं क्योंकि मैं यह देखने के लिए एक समाधान प्राप्त करने के साथ भी नहीं खेल सकता कि क्या यह टाइपस्क्रिप्ट रोने और मेरे रेंडर को अवरुद्ध किए बिना भी व्यवहार्य है।

वर्तमान में हमें इस सुविधा की आवश्यकता है।

हम एक सार्वजनिक पुस्तकालय का आयात कर रहे हैं जिसमें कुछ कार्यों के लिए नोड प्रकार हैं जिनमें हम रुचि नहीं रखते हैं। इसलिए एकल आयात के लिए // @ ts-ignore का उपयोग करना अच्छा होगा, बजाय skipLibCheck को अनदेखा करने के लिए सभी lib.

शुरू में मुझे//@ ts-ignore-file विचार पसंद आया, लेकिन//@ ts-ignore शायद निरंतरता के लिए बेहतर काम करेगा।

तो.... मैंने टाइपस्क्रिप्ट फ़ाइलों में //@ts-nocheck के समर्थन के साथ #33383 खोला। अब, हम _टाइपस्क्रिप्ट_ कंपाइलर टीम होने के नाते, हम वास्तव में इसे प्राप्त नहीं करते हैं, हम स्वयं (संभावित समस्याओं को ठीक नहीं कर रहे हैं, व्हाट !!?!?) - यहां तक ​​​​कि //@ts-ignore टाइपस्क्रिप्ट में केवल एक चीज बन गई क्योंकि हमारी बांह मुड़ गई थी थोड़ा सा, तो हम... संकोच कर रहे हैं... और दमन तंत्र जोड़ने के लिए। इसलिए यदि आप वास्तव में महसूस करते हैं कि इस तरह के व्यापक दमन तंत्र की आवश्यकता है, तो अच्छा होगा यदि आप वहां जा सकें और

@weswigham , हालांकि यह शायद सबसे महत्वपूर्ण विशेषताओं में से नहीं है। यह विकास के दौरान आसान हो सकता है। कोड की कुछ पंक्तियों पर अस्थायी टिप्पणी करने की तरह, यह किसी समस्या को कहीं और विकसित करने और अलग करने का प्रयास करते समय सहायक हो सकता है। हालांकि मैं एक चेतावनी प्राप्त करना चाहता हूं, इसलिए इस अभ्यास को वास्तव में रन टाइम बग का कारण बनने का तरीका नहीं मिलेगा। शायद इस सुविधा को केवल विकास के लिए सक्षम करें, लेकिन निर्माण पर एक त्रुटि फेंकने के लिए।

चूंकि इस मुद्दे को अभी भी "अधिक प्रतिक्रिया की प्रतीक्षा" के रूप में लेबल किया गया है, यहां और भी कुछ है:

नए आर्किटेक्चरल दिशाओं को जल्दी से प्रोटोटाइप करते समय, मैं यह सुनिश्चित करने के लिए टाइपस्क्रिप्ट द्वारा निर्देशित करना चाहता हूं, यह सुनिश्चित करने के लिए कि नया आर्किटेक्चर काम करेगा। हालांकि, मैं अस्थायी रूप से यूनिट परीक्षण फ़ाइलों में टाइप त्रुटियों को अस्थायी रूप से अनदेखा करना चाहता हूं, जबकि मैं प्रयोग करता हूं।

प्रत्येक फ़ाइल के शीर्ष पर किसी प्रकार की @ts-ignore- टिप्पणी जोड़ना काफी आसान होगा।

मैं दूसरा @ kumar303 की जरूरत है: यूनिट परीक्षण में उस दिए गए ब्लॉक/फ़ाइल के लिए कुछ चेक बंद करना फायदेमंद है, क्योंकि यह उन मामलों को कवर करने वाले दावे होंगे।

@weswigham आप इसे एक कंपाइलर ध्वज के पीछे रख सकते हैं।

आप इसे एक कंपाइलर ध्वज के पीछे रख सकते हैं।

कोई ज़रूरत नहीं - यह 3.7 बीटा में है।

पुन: https://github.com/microsoft/TypeScript/pull/33383 : @weswigham यह बहुत अच्छा है, धन्यवाद! यहां एक शक्तिशाली उपयोग का मामला फ़ाइल में टाइप चेकिंग को अस्थायी रूप से अनदेखा करना है, इसलिए मेरा सुझाव है कि एक लिंट नियम को शिप करें जो विफल हो जाता है जब कोई @ts-nocheck को हटाना भूल जाता है

गैट्सबी पर एक समस्या है, जहां एक स्थिर ग्राफक्यूएल क्वेरी .jsx फाइलों में काम करती है, लेकिन .tsx फाइलों में नहीं। मुझे लगता है कि यह प्रस्ताव एक अधिक स्वीकार्य कार्य-आसपास हो सकता है। (यहां जारी करें https://github.com/AdamLeBlanc/gatsby-plugin-ts-loader/issues/5)

अरे!
क्या प्रस्तावित समाधान लागू किया गया है?

// @ ts-अनदेखा-शुरू
// @ टीएस-अनदेखा-अंत

मुझे लगता है कि यह बेहद फायदेमंद होगा। मुझे इस पर काम करने में कोई आपत्ति नहीं होगी।

हमने 3.7 में संपूर्ण फ़ाइल में सभी त्रुटियों को दबाने के लिए //@ts-nocheck के लिए समर्थन जोड़ा। मुझे लगता है कि लाइन-स्तर और फ़ाइल-स्तरीय दमन बिना किसी परेशानी के _most_ जरूरतों को शामिल कर सकता है। यदि आपके पास एक चेक की गई फ़ाइल के भीतर पर्याप्त रूप से बड़ा ब्लॉक है जिसे अनियंत्रित किया जाना चाहिए, तो शायद पूरी फ़ाइल के लिए जांच अक्षम कर दें या, यह अरुचिकर होना चाहिए, अनियंत्रित खंड को अपनी फ़ाइल में निकालें और उस फ़ाइल के लिए जांच अक्षम करें या असफल होने पर, प्रत्येक पंक्ति को वास्तविक मुद्दे से दबाएं? एक 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 ) या प्रत्येक व्यक्तिगत बुरी चीज (tm) पर व्यक्तिगत दमन ( //@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 ) पसंद करूंगा। मैं, मेरे जीवन के लिए, एक सम्मोहक, सैद्धांतिक उदाहरण के साथ नहीं आ सकता, जहां विशिष्ट _ranges_ कोड को अनियंत्रित होने की अनुमति दी जानी चाहिए (फाइलों के विपरीत, जिसमें एक स्पष्ट प्रवास-रणनीति-समर्थित तर्क था), "लगातार कई लिखने के अलावा" दमन मेरी आँखों से खून बहाता है", जिसके लिए मुझे _zero_ सहानुभूति है, मूल रूप से, हम मानते हैं कि आपको टाइपस्क्रिप्ट में दमन का उपयोग बिल्कुल नहीं करना चाहिए। यदि यह एक प्रकार का मुद्दा है, तो आप इससे बाहर निकल सकते हैं (इसीलिए any , कास्टिंग, और शॉर्टहैंड मॉड्यूल घोषणाएं मौजूद हैं)। यदि यह एक सिंटैक्स समस्या है, तो सब कुछ भयानक है और हम वैसे भी टूट जाएंगे, इसलिए दमन कुछ भी नहीं करेगा (दमन पार्स त्रुटियों को प्रभावित नहीं करता है)।

//@ts-nocheck के लिए धन्यवाद, लेकिन यह कोड ब्लॉक के लिए चेक अक्षम करने की समस्या का समाधान नहीं करता है:

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

// @ts-nocheck

मेरे पास एक दिलचस्प उपयोगकेस है।

हमने टाइपस्क्रिप्ट में ओआरएम बनाया या उसका मालिक है जो हमारे डीडीएल में बयान संकलित करने के लिए एकोर्न का उपयोग करता है।

एक क्वेरी करने के लिए हमें इसे स्कोप्ड वेरिएबल्स पास करना होगा:

.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 कास्ट (या, jsdoc, /** <strong i="8">@type</strong> {any} */(expr) ) होना चाहिए, यदि आप वास्तव में इसे दबाना चाहते हैं।

//@ts-nocheck मेरे ts कोणीय प्रोजेक्ट के लिए काम नहीं करता है लेकिन //@ts-ignore करता है। Microsoft के लिए यह समस्या 2017 में शुरू हुई थी! बहुत खूब...

3 साल अब और कोई समाधान नहीं। इसमें कोई आश्चर्य की बात नहीं है कि जावास्क्रिप्ट डेवलपर्स टाइपस्क्रिप्ट पर छलांग नहीं लगाना चाहते हैं

// @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
वर्तमान में एकमात्र विकल्प है :(

यहां विचार के लिए जोड़ने के लिए एक और उपयोग का मामला ...

मैं एक इन-हाउस मार्कअप भाषा से टाइपस्क्रिप्ट कोड का एक गुच्छा उत्पन्न करने वाला कोड हूं जो कुछ बुनियादी नियंत्रण प्रवाह और सशर्त अनुमति देता है। जबकि मैं कोड जनरेशन व्यवहार को नियंत्रित करता हूं, मैं कोड जनरेटर को दिए गए इनपुट को नियंत्रित नहीं करता (जो कि अंतिम उपयोगकर्ताओं तक है)

नतीजतन, उत्पन्न कोड में आसानी से पहुंच योग्य कोड नहीं हो सकता है, या एक मामले में TS2367 हो सकता है क्योंकि नेस्टेड कोड हो सकता है जो एक एनम स्थिरांक के खिलाफ एक मूल्य का परीक्षण करता है, फिर उस ब्लॉक के अंदर उस चर का एक और एनम स्थिरांक के खिलाफ एक और चेक होता है। उदाहरण के लिए:

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

हस्तलिखित कोड के साथ, इस पैटर्न को ठीक करना और टालना आसान है। कोड जनरेशन के साथ, हालांकि, यह मेरे उपयोगकर्ताओं पर निर्भर है (डेवलपर्स, आप प्रकार जानते हैं!)

मैं टाइपचेकिंग को पूरी तरह से अक्षम नहीं करना चाहता, लेकिन इस त्रुटि के कारण कोड-जनरेटेड कोड का उपभोग करने के लिए मेरे पास कोई अन्य तंत्र नहीं है। आदर्श रूप से मैं सभी कोड-जनरेटेड फाइलों के लिए इस एक त्रुटि को दबा दूंगा, लेकिन अन्य सभी प्रकार की जांच को बनाए रखूंगा।

वैसे भी, मेरे पास सभी प्रकार की जांच बंद करने के अलावा कोई समाधान नहीं है। किस बिंदु पर मुझे टाइपस्क्रिप्ट बनाम सादा जावास्क्रिप्ट से अधिक मूल्य नहीं मिल रहा है

क्या आप गंभीर हैं? यह अभी भी एक खुला मुद्दा है और TS4 में लागू नहीं किया गया है? मैं

@ivnnv आप TS 3.9 में // @ts-expect-error का उपयोग कर सकते हैं, यहां देखें

@ndraiman @ts-expect-error अलग-अलग लाइनों के लिए काम करता है लेकिन ब्लॉक के लिए नहीं, इसलिए यदि कोई "ब्लॉक को अनदेखा करना" चाहता है तो उनमें से कई को रखने की आवश्यकता है

यहां आपके लिए कुछ और फ़ीडबैक दिए गए हैं:

आपको और क्या चाहिए? इस कार्यक्षमता को प्राप्त करने के लिए समुदाय को क्या करना है?

इसके लिए सबसे अच्छा उपयोग केस प्रत्येक प्रकार के बनाने पर any लिखने का विकल्प है। आपको सौंदर्यशास्त्र के लिए सहानुभूति नहीं हो सकती है (जिसका मूड और उत्पादकता पर कोई प्रभाव पड़ता है), लेकिन केवल एक विकल्प है जो आम अपेक्षाओं से मेल खाता है, इसे स्वीकार करना मुश्किल नहीं होना चाहिए।

क्या स्वीकार्य है और क्या नहीं, इस पर लोगों के अलग-अलग विचार हैं।

कुछ लोगों के लिए, यह बहुत समय लेने वाला है और पोर्टिंग कोड जैसे सांसारिक सामान करते समय प्रवाह-स्थिति वाले लोगों को सीमित कर सकता है।
मुझे यह कष्टप्रद और अजीब लगता है कि मेरे पास कोड का एक अनदेखा ब्लॉक नहीं हो सकता है, बल्कि इसे any कास्ट के साथ लिटाना पड़ता है, जो अक्सर पठनीयता पर हानिकारक प्रभाव डालता है (जब तक कि उचित प्रकार न हों)। लगातार एक नई टिप्पणी लिखने या व्याकुलता में लिप्त होने के कारण _ अन्याय क्योंकि किसी को कोड_ के ब्लॉक को अनदेखा करने का लाभ नहीं दिखता है, यह मेरे दृष्टिकोण से ठीक नहीं है।

उदाहरण:

एक प्रोजेक्ट को JS से TS में पोर्ट कर रहा है, जबकि दूसरा प्रोजेक्ट किसी तीसरे पक्ष द्वारा विकसित किया जा रहा है।

पोर्ट किए गए प्रोजेक्ट में अपनाए गए सिंटैक्स और नियम या तो पुराने e,g, es2015 हो सकते हैं, या स्पष्ट सिंटैक्स और कम कोड आदि के पक्ष में पदावनत हो सकते हैं।

इस प्रोजेक्ट को पोर्ट करते समय, कुछ कोड टाइपस्क्रिप्ट में पोर्ट करना बेहद आसान हो सकता है। फिर भी, एक अनिवार्य रूप से चलता है, उदाहरण के लिए, बुलियन के माध्यम से आधा विचार और मनमाने व्यवहार के साथ कार्य करता है जिसे या तो अधिक संदर्भ की आवश्यकता होती है या इसके प्रकार बनाने के लिए कुछ समय के लिए सोचा जाना चाहिए।

किसी फ़ाइल को ठीक करते समय किसी फ़ंक्शन या कोड के ब्लॉक को चेक करना बंद करना बहुत बढ़िया होगा। एक कोड-ब्लॉक को अनदेखा करने से व्यक्ति उन क्षेत्रों में तेज़ी से आगे बढ़ सकता है जिन्हें वे जानते हैं और बाद में कुछ हिस्सों को सहेज सकते हैं और सहेज सकते हैं।

मेरा वर्कफ़्लो जब मुझे जावास्क्रिप्ट को टाइपस्क्रिप्ट में पोर्ट करना है (और कोड है, ठीक है, सबपर):

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. जैसे ही मैं उन्हें प्राप्त करता हूं और प्रकार जोड़ता हूं, उन्हें अनकम्मेंट ब्लॉक करें

अपने लिए तय करें कि सबसे उचित क्या लगता है। यह वही है जब किसी प्रोजेक्ट में JS को अधिक ESLint नियमों के साथ पोर्ट किया जाता है, और आपको अधिकांश सामानों को दोबारा करना होगा।

काश हम ESLint में ऐसा कर पाते और टाइपस्क्रिप्ट में /* eslint:disable */ ... /* eslint:enable */ का उपयोग करते।

पीएस मुझे इस टिप्पणी की जांच करते समय अभी एहसास हुआ कि मैंने 20 मिनट + एक अनुभव प्राप्त करने की कोशिश कर रहा है जिसे मैं (और कई अन्य) 2017 से मांग रहा हूं, बस जल्द ही 3 साल पुराने खुले मुद्दे पर टिप्पणी करने के लिए।

@weswigham @RyanCavanaugh

अनुस्मारक: +1:

इसके बदले ज्येष्ठ पुत्र देंगे

@augusterodin आपका बलिदान बुराइयों का ध्यान खींचता है.....

ठीक है, वास्तव में कुछ भी नहीं होता है, सिवाय इसके कि मैं सिर्फ एक साधारण पीआर देता हूं :)

हालांकि, व्यक्तिगत रूप से, मैं टीएस टीम की राय से दृढ़ता से सहमत हूं - यह कार्य बुरा है, आपको हमेशा @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.

एक आदर्श दुनिया में, हमें टाइप सेफ्टी को नज़रअंदाज़ करने की ज़रूरत नहीं होगी, है ना? :पसीना_मुस्कुराना:
शानदार काम की नकल करते समय मुझे इसकी आवश्यकता होती है, उदाहरण और शुरुआत, यहां तक ​​​​कि कभी-कभी 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 का उपयोग करके किसी ऐप को माइग्रेट करने का प्रयास करते समय, मुझे एक समस्या का सामना करना पड़ा जहां @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 टीम को इस बात का अहसास नहीं है कि "मौलिक रूप से, हमारा मानना ​​है कि आपको टाइपस्क्रिप्ट में दमन का उपयोग बिल्कुल भी नहीं करना चाहिए।" रहने और सांस लेने पर आधारित एक राय है टाइपस्क्रिप्ट, और वास्तविक दुनिया में, लोगों को खराब लिखित कोड को अन्य कोडबेस में पोर्ट करने की आवश्यकता होती है, अधिक प्रकार की सुरक्षा और अन्य लाइनिंग नियमों के साथ; उन स्थितियों में, इसका कोई मतलब नहीं है कि आप किसी फ़ाइल या लाइन को अनदेखा कर सकते हैं, लेकिन उस कोड के ब्लॉक को नहीं जिसे आपने अभी-अभी आयात किया है।

मेरे लिए, ऐसा लगता है कि आप वास्तविकता को नजरअंदाज करते हुए यूटोपिया की ओर जा रहे हैं। @sandersn आपने मेरे किसी भी बिंदु को संबोधित नहीं किया और मामले में नई चर्चाओं पर पुरानी प्रतिक्रिया को पकड़ लिया। आप यह भी कहते हैं कि जब तक टीम अन्यथा निर्णय नहीं लेती, इसे लागू नहीं किया जाना चाहिए, इस मामले में: इस मुद्दे को बंद करें?

टीम को या तो निर्णय लेने या स्पष्ट रूप से वांछित विशेषता को लागू करने की आवश्यकता होती है।

मामले को ठंडे बस्ते में डालने का कोई मतलब नहीं है।

मुझे खेद है कि हम आपको वह अंतिम रूप नहीं दे सकते जिसकी आपको आवश्यकता है, लेकिन वास्तविकता यह है कि "शायद बाद में" एक ऐसा उत्तर है जिसके साथ आपको जीना सीखना होगा। किसी भी दी गई सुविधा को कल उत्पाद में नहीं लाया जा सकता है, और हमारे डिज़ाइन मापदंडों के भीतर आने वाली सुविधाओं के लिए, हजारों वर्तमान में खुले सुझाव हैं जो उत्पाद में उन्हें जोड़ने की हमारी क्षमता के लिए प्रतिस्पर्धा कर रहे हैं जो कि एर्गोनोमिक है, उपयोगी, स्थिर और आगे की सोच।

हम मौजूदा फीडबैक, मौजूदा समाधानों और वर्कअराउंड की स्थिति, उन परिदृश्यों की प्रधानता, टूलिंग और सौ अन्य कारकों के आधार पर चीजों को प्राथमिकता देते हैं। जो चीजें अभी उच्च-प्राथमिकता नहीं हैं, वे बाद में उच्च-प्राथमिकता बन सकती हैं। यह "शायद बाद में" की प्रकृति है और मुझे लगता है कि यह एक सटीक प्रतिनिधित्व है जहां यह सुझाव है। अभी के लिए, यहाँ निर्णय फीडबैक की निगरानी करना और यह समझना है कि लोग क्या कर रहे हैं, इस सुविधा को किसी भी अन्य सुविधा की तुलना में उच्च प्राथमिकता के रूप में आवश्यक हो सकता है, जिसे हम आगे जोड़ सकते हैं, जिनमें से सैकड़ों ध्यान देने के लिए प्रतिस्पर्धा कर रहे हैं।

यहाँ स्वर ईमानदारी से शत्रुतापूर्ण और व्यक्तिगत रूप से बोल रहा है, एक अल्टीमेटम की ओर धकेल दिया जाना एक रचनात्मक बातचीत के लिए अनुकूल नहीं है जो हमें यह समझने में मदद करता है कि यह कहां मूल्य जोड़ रहा है जो विकल्पों के सापेक्ष इसकी जटिलता को दूर करता है।

मुझे अल्टीमेटम सेट करने के लिए खेद है। मुझे पीआर के प्रति गतिविधि देखकर काफी गुस्सा आया, लेकिन इस मुद्दे पर कोई नहीं। मैं सहमत हूं कि मेरी पिछली टिप्पणी किसी भी रचनात्मक तरीके से योगदान नहीं देती है।

मैं स्वीकार कर सकता हूं कि इस मुद्दे को प्रतीक्षा करने की आवश्यकता हो सकती है। मैंने कुछ प्रतिक्रिया प्रदान की और पूछा कि संकल्प के करीब जाने के लिए और क्या प्रतिक्रिया आवश्यक है, लेकिन मुझे कोई प्रतिक्रिया नहीं मिली। ऐसा लगता है, हालांकि यह कष्टप्रद हो सकता है, कि मेरी असंरचित टिप्पणी वह थी जो मुझे टीम से _some_ प्रतिक्रिया प्राप्त करने के लिए करने की आवश्यकता थी।

ऐसा अभी भी लगता है कि 700 से अधिक सकारात्मक प्रतिक्रियाओं के साथ किसी मुद्दे की ओर कोई वास्तविक प्रगति नहीं हुई है, जो कि कई साल पुरानी है। मुझे विश्वास नहीं है कि इसे तेजी से आगे बढ़ना चाहिए, लेकिन ऐसा लगता है कि टीम इस सुविधा की खोज में रूचि नहीं ले रही है क्योंकि सदस्यों की इसके खिलाफ व्यक्तिगत राय है। मैं इन सब बातों को पूरी तरह से समझता हूं। हालाँकि मैं यहाँ इस बारे में नहीं हूँ। मैं कुछ बातचीत करना चाहता हूं, लेकिन मुझे नजरअंदाज किया जा रहा है।

मैं जानना चाहता हूं कि मेरी प्रतिक्रिया पर विचार किया गया है, और इसकी प्रकृति को देखते हुए, प्रतिक्रिया दी गई है। सक्रिय पीआर द्वारा दिखाए गए फीचर-सेट में यह एक बड़ा व्यवधान नहीं है, जो थोड़े समय में व्हीप्ड हो गया। सब कुछ जाने के लिए तैयार है, लोग इस मुद्दे को एक ब्लॉक अनदेखा सुविधा के साथ हल करने के लिए सकारात्मक प्रतिक्रिया देते रहते हैं, और मैंने यह पूछने में चिल्लाया कि इस सुविधा को प्राप्त करने के लिए समुदाय को क्या करना है। मैं टीम द्वारा किए जा रहे कई बिंदुओं से पूरी तरह असहमत हूं और इसके खिलाफ तर्क दिया है, एक पीआर किया गया था और एक टिप्पणी दी गई थी जिसमें कहा गया था कि 'जब तक हम अपना विचार नहीं बदलते' कुछ भी नहीं बदलेगा।

यहीं से मेरी हताशा सामने आती है। आप एक तैयार सुविधा की अवहेलना करना चाहते हैं क्योंकि टीम के किसी सदस्य के निर्णय में कोई बदलाव नहीं किया गया है, मेरे अपने और अन्य लोगों की प्रतिक्रिया को पूरी तरह से अनदेखा कर दिया गया है।

ऐसा लगता है कि जब तक टीम का कोई व्यक्ति _अपनी सहमति पर_ निर्णय नहीं लेता, हम इस मुद्दे पर कोई बदलाव नहीं देखेंगे। यह समुदाय से अधिक प्रतिक्रिया की मांग नहीं करता है, है ना? इसलिए मैंने गलत तरीके से अल्टीमेटम दिया।

मैंने @weswigham के बिंदुओं के खिलाफ कई तर्क दिए हैं, कुछ उदाहरण दिए हैं, और ईमानदारी से अभी भी किसी तरह की प्रतिक्रिया की प्रतीक्षा कर रहा हूं। केवल एक चीज जो मददगार लगती थी, वह थी स्पष्ट रूप से परेशान और असंरचित।

हम यहां से कैसे आगे बढ़ते हैं? टीम क्या प्रतिक्रिया पसंद करेगी? ऐसा लगता है कि "हम वर्तमान फीडबैक, वर्तमान समाधानों और वर्कअराउंड की स्थिति, उन परिदृश्यों की प्रबलता, टूलिंग और सौ अन्य कारकों के आधार पर चीजों को प्राथमिकता देते हैं।" चूंकि कई लोगों ने टीम की ओर से बिना किसी प्रतिक्रिया के प्रतिक्रिया देने की कोशिश की है।

मैं यह दोहराना चाहूंगा कि मैं समझता हूं कि यदि हम इस विषय से लोगों की राय को दूर करते हैं तो यह एक उच्च प्राथमिकता नहीं हो सकती है। साथ ही, सुविधा लागू करने के लिए तैयार है, और तर्क दिए गए हैं। अब जरूरत इस बात की है कि टीम निर्णय/प्रतिक्रिया करे (जरूरी नहीं कि कुछ भी लागू करे) और उसे सार्वजनिक करे। यदि यह आवश्यक नहीं है, तो कृपया मुझे बताएं कि क्या है, या टाइपस्क्रिप्ट के लिए _any_ सुविधा या मुद्दे पर प्राथमिकता को बढ़ाने में कोई कैसे मदद करेगा, लेकिन विशेष रूप से यह एक।

मल्टीलाइन ( @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...
}

वर्णित स्थिति के लिए टाइपस्क्रिप्ट निम्नलिखित चेतावनी देता है: '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

जो अजीब और बदसूरत है।

@RyanCavanaugh @weswigham @sandersn

एक मासिक अनुस्मारक कि यह कुछ ऐसा है जिस पर समुदाय टाइपस्क्रिप्ट टीम के साथ आगे चर्चा करना चाहता है। बहुत समर्थन है और वर्तमान में जो गायब है वह टीम की प्रतिक्रिया है। मुझे लगता है कि इसमें बहुत अधिक प्रीपोंडरिंग है, और टाइपस्क्रिप्ट को आगे बढ़ाना कोई आसान उपलब्धि नहीं है। चीजें समय लेती हैं। चूंकि इस बारे में कोई प्रतिक्रिया नहीं है कि हम इस सुझाव को कैसे आगे बढ़ा सकते हैं और कुछ और सीधी कार्रवाई कर सकते हैं, इसलिए मैं नियमित रूप से इस तरह का एक रिमाइंडर दूंगा। मैं तब तक हार नहीं मान रहा हूं जब तक कि कोई निर्णय नहीं हो जाता है, और टिप्पणी करने से प्रभाव पड़ता है (ज्यादातर जब एक !@# होने पर)।

इन वर्षों के बीत जाने के बाद, हालांकि मैं मूल रूप से इस बात से हैरान था कि यह कार्यक्षमता कैसे नहीं है, मैंने व्यक्तिगत रूप से इस पर थोड़ा पुनर्विचार किया ... जब @ts-ignore का एक बड़ा गुच्छा होता है, तो आप पहले ही बता सकते हैं कि कुछ गड़बड़ है अपने कोड के साथ, और अपने प्रकारों को बेहतर बनाने के लिए कुछ समय बिताएं। हम सभी कभी-कभी बहुत आलसी होते हैं, और समग्र रूप से गति चाहते हैं, लेकिन वर्तमान में कोड के बड़े समूहों में कई @ts-ignore को कॉपी-पेस्ट करने के बजाय कुछ उचित प्रकारों का पता लगाना अक्सर आसान होता है। यदि असुविधा का यह संतुलन टूट जाता है, तो हम में से बहुत से लोग @ts-ignore-enable का आसानी से दुरुपयोग कर रहे होंगे, जो यहां और वहां सभी छोटे ओपन सोर्स प्रोजेक्ट्स की समग्र गुणवत्ता को कम कर सकता है।

बीटीडब्ल्यू, हालांकि हम देखते हैं कि इस मुद्दे पर कई प्रतिक्रियाएं हैं, - यह पक्षपातपूर्ण हो सकता है, क्योंकि बहुत सारे लोग चुप रहते हुए इस सुविधा के बिना पूरी तरह से ठीक महसूस कर सकते हैं, क्योंकि वे यहां नहीं हैं।

@JerryGreen मेरी पुरानी टिप्पणियों का संदर्भ देते हुए, मैंने ठीक यही बात कही है। इसके अलावा लोग पहले से ही इसे इग्नोर फीचर के साथ कर रहे हैं। _none_ होने का दावा करते हुए हर समय थोड़ा सा जहर लागू करने का कोई कारण नहीं है।

या तो @ts-ignore कार्यक्षमता को हटा दें या इसे पूरी तरह से विकसित कर दें। ऐसा करने के लिए कई तर्क हैं, और खराब कोड लिखने वाले लोग @ts-ignore का उपयोग करना जारी रखेंगे, जो कि एक ब्लॉक की अनदेखी सुविधा के समान ही खराब है, वे ठीक उसी चीज हैं - ब्लॉक को छोड़कर, कम दृष्टि से विघटनकारी होने के कारण।

समुदाय को अभी भी टाइपस्क्रिप्ट टीम से प्रतिक्रिया की आवश्यकता है।

@JerryGreen मेरी पुरानी टिप्पणियों का संदर्भ देते हुए, मैंने ठीक यही बात कही है। इसके अलावा लोग पहले से ही इसे इग्नोर फीचर के साथ कर रहे हैं। _none_ होने का दावा करते हुए हर समय थोड़ा सा जहर लागू करने का कोई कारण नहीं है।

या तो @ts-ignore कार्यक्षमता को हटा दें या इसे पूरी तरह से विकसित कर दें। ऐसा करने के लिए कई तर्क हैं, और खराब कोड लिखने वाले लोग @ts-ignore का उपयोग करना जारी रखेंगे, जो कि एक ब्लॉक की अनदेखी सुविधा के समान ही खराब है, वे ठीक उसी चीज हैं - ब्लॉक को छोड़कर, कम दृष्टि से विघटनकारी होने के कारण।

समुदाय को अभी भी टाइपस्क्रिप्ट टीम से प्रतिक्रिया की आवश्यकता है।

कुछ विशेष परिदृश्यों को अभी भी @ TS उपेक्षा का उपयोग करने की आवश्यकता है। उदाहरण के लिए, सीडीएन आयात नोड_ पर निर्भर नहीं करता है। TS फ़ाइल मॉड्यूल परिदृश्य में मौजूद नहीं है

@ एल-हक्नु स्पष्टीकरण के लिए धन्यवाद। लोग इसका उपयोग करते हैं क्योंकि वे वैसे भी ESLint के साथ अनदेखा करते हैं।

जहां कार्यक्षमता के लिए इसकी आवश्यकता है, इसके अलावा संदर्भों में उपेक्षा कार्यक्षमता की अनुमति नहीं है। यह मुझे बताता है कि कोड को अनदेखा करने के लिए इसका उपयोग करना ठीक है।

मैं अभी भी यह नहीं समझ सकता कि ब्लॉक को अनदेखा क्यों नहीं किया जाना चाहिए, क्योंकि इसका उपयोग ज्यादातर समय उसी तरह किया जाता है।

मैंने कुछ ओपन सोर्स कोड के लिए प्रकारों में कनवर्ट करना छोड़ दिया है, क्योंकि कनवर्ट करने की प्रगति ब्लॉक अनदेखा के साथ और अधिक आरामदायक होती। मुझे इसकी आवश्यकता नहीं है, लेकिन मुझे लगता है कि टाइपिंग के साथ बहुत से लोगों को दरवाजे के अंदर पैर मिल जाएगा; इसके अलावा, बहुत से लोग रूपांतरणों में अधिक कुशलता से योगदान देंगे, विशेष रूप से यह देखते हुए कि ब्लॉक और हर-पंक्ति टिप्पणियों के बीच सौंदर्यशास्त्र कितना भिन्न है।

इस कार्यान्वयन के लिए मेरा सबसे बड़ा उपयोग मामला तीसरे पक्ष के पैकेज के लिए होगा जिसमें टाइपस्क्रिप्ट समर्थन नहीं है, और मुझे इसके कुछ उपयोगों को अनदेखा करना होगा।

@ एल-हक्नु स्पष्टीकरण के लिए धन्यवाद। लोग इसका उपयोग करते हैं क्योंकि वे वैसे भी ESLint के साथ अनदेखा करते हैं।

जहां कार्यक्षमता के लिए इसकी आवश्यकता है, इसके अलावा संदर्भों में उपेक्षा कार्यक्षमता की अनुमति नहीं है। यह मुझे बताता है कि कोड को अनदेखा करने के लिए इसका उपयोग करना ठीक है।

मैं अभी भी यह नहीं समझ सकता कि ब्लॉक को अनदेखा क्यों नहीं किया जाना चाहिए, क्योंकि इसका उपयोग ज्यादातर समय उसी तरह किया जाता है।

मैंने कुछ ओपन सोर्स कोड के लिए प्रकारों में कनवर्ट करना छोड़ दिया है, क्योंकि कनवर्ट करने की प्रगति ब्लॉक अनदेखा के साथ और अधिक आरामदायक होती। मुझे इसकी आवश्यकता नहीं है, लेकिन मुझे लगता है कि टाइपिंग के साथ बहुत से लोगों को दरवाजे के अंदर पैर मिल जाएगा; इसके अलावा, बहुत से लोग रूपांतरणों में अधिक कुशलता से योगदान देंगे, विशेष रूप से यह देखते हुए कि ब्लॉक और हर-पंक्ति टिप्पणियों के बीच सौंदर्यशास्त्र कितना भिन्न है।

ऐसा लगता है कि यह हो गया
#40267