brauche das lol

Der aktuelle Anwendungsfall für diese Funktion ist ein Komponententest, der sich mit Leerzeichen befasst. Wir haben die „No-Trailing-Whitespace“-Regel aus gutem Grund in unserer Codebasis aktiviert, aber da wir sie nicht auf Blockebene überwältigen können, können wir mit einer ES6-Vorlagenzeichenfolge nicht einfach auf abschließende Whitespaces und Wagenrückläufe testen .

einer meiner Anwendungsfälle, um benutzerdefinierte Bündelung _ a.k.a partial import _ in mathjs zu verwenden

// 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

Ich möchte Fehler für eine ganze Datei ignorieren. Ich habe einen ES6-JS-Code geerbt, den ich auf ES5 transpilieren möchte, aber im Moment Babel verwenden muss. Wäre schön, die Datei einfach in .ts umzubenennen und mit TS zu transpilieren.

@ptallett Sie können einfach .js Dateien mit allowJs kompilieren und in die Kompilierung aufnehmen. Standardmäßig geben wir keine Fehler bei .js -Dateien aus, es sei denn, die Datei hat oben einen // @ts-check -Kommentar oder Sie aktivieren checkJs .

Ich würde diese Funktionalität immer noch lieben, ich sitze in einer Testdatei, sie hat die Erweiterung .ts, sodass ich importieren und leicht sehen kann, welche Parameter wohin gehen, und das Kompilieren in ein Verzeichnis neben den src-Dateien ist für meinen Anwendungsfall brillant .

Die meisten meiner Zeilen sind jetzt rot, da ich absichtlich versuche, einige Parameter auszuschließen oder der Funktion einen anderen Typ zu geben, als sie ursprünglich benötigt, und erwarte, dass ein Fehler ausgegeben wird, da ich ihn auch zur Laufzeit überprüfe.

Es wäre schön, nicht überall ein paar rote Linien zu haben. :)

Gibt es dazu ein Update oder hat jemand eine gute Möglichkeit gefunden, dies zu tun?

Die Verwendung lodash und insbesondere lodash/fp mit TypeScript ist so schmerzhaft, und selbst mit den neuesten Versionen von lodash und @types/lodash können Sie mit sehr kryptischen Fehlermeldungen enden.

Wenn wir einen @ts-ignore-block haben könnten, der Fehler für den folgenden Block ignoriert, wäre das großartig für Anwendungsfälle wie diesen, wo _du weißt, was du tust_ :-)

Ich arbeite mit Legacy-Code mit zahlreichen Variablen mit globalem Gültigkeitsbereich, und das Schreiben von @ts-ignore in jede Zeile ist mühsam geworden. Gibt es Updates dazu?

Bitten Sie auch um ein Update zu dieser Anfrage. Danke!

Dies wäre auch sehr wichtig für das, was ich tue (nämlich die Typprüfung generierter Vue-Vorlagen-Renderfunktionen, die das Deaktivieren bestimmter Inspektionen für einen Codeblock erfordern würden.)
Zusammen mit diesem Problem wäre #19139 sehr wichtig, da Sie insbesondere bei der Anwendung auf große Teile des Codes nur bestimmte Inspektionen deaktivieren möchten.

Mit dem Unterdrücken der Lochdatei könnte dies zu Editoren wie vs Code hinzugefügt werden, um in den Arbeitsbereichseinstellungen oder dergleichen zu speichern.

Brauche das auch. Ich generiere automatisch eine ganze TS-Datei mit Typen für mein GraphQL-Schema mit graphql-code-generator und es gibt einen fremden Import, der noUnusedLocals auslöst.

/* tslint:deaktivieren */

Code

/* tslint:enable */

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

Kombinierbar mit: 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 das ist nicht tslint.

Manchmal möchte ich beim Verschieben und Refactoring die gesamte Datei vorübergehend ignorieren (dh nicht kompilieren), ohne mit den CLI-Optionen herumzuspielen.

Am schnellsten/einfachsten ist ein Flag am Anfang der Datei:

// @ts-ignore-file

@lonix1 Ihr Anwendungsfall wird abgedeckt von:

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

Sie müssen den Teil // @ts-ignore-end nicht verwenden. Viele Fusselwerkzeuge funktionieren auf diese Weise.

@mgol Ich möchte diesen Thread nicht entgleisen ... aber ich habe deinen Vorschlag ausprobiert - danke! - und es hat bei mir nicht funktioniert. Ich habe die Zeilen oben in der Datei zusammengefügt und auch eine oben und die andere unten versucht.
Kann es jemand anderes zum Laufen bringen?

@lonix1 Ich meinte, dass der Vorschlag von @Blanen auch für Sie funktionieren würde, wir brauchen TypeScript nicht, um sowohl // @ts-ignore-start + // @ts-ignore-end als auch // @ts-ignore-file zu implementieren und // @ts-ignore-start zu implementieren // @ts-ignore-end würde reichen. Dies ist nicht implementiert, deshalb ist dieses Problem noch offen.

@DanielRosenwasser dies würde nur funktionieren, wenn die ts-Dateien während des Builds in einem anderen Ordner gespeichert werden. Wenn das Projekt so eingerichtet ist, dass js-Dateien neben den ts-Dateien platziert werden, wird dies nicht der Fall sein. Werden auch js-Dateien "kompiliert", z. B. in es5 umgewandelt? Beim Transport von Legacy-Code wäre dies wirklich hilfreich.

Benötige diese Funktion.

Anwendungsfall:

TypeORM erwartet, dass wir DB-Entitätsklassen erstellen, die Spalten haben, die nullfähig sein können oder nicht. Viele Spalten sind (daher) nicht nullable ... und sollten daher behandelt werden, außer in der Klassendefinition, als ob die Eigenschaften unbedingt von bestimmten definierten Typen sind. Typescript erfordert jedoch, dass wir jede Spalte als stark typisiert definieren. Daher haben wir am Ende sehr viele Entitäten wie:

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

Jede Spalte ist erforderlich und muss (daher) sicher einen Wert enthalten, aber aufgrund der Funktionsweise von TypeORM muss jede Eigenschaft so definiert werden, dass sie keinen Initialisierer hat. Es wäre äußerst praktisch, dieses spezielle ORM-abgeleitete/spezifische Problem für eine ganze Klasse (daher/oder eine Datei) unterdrücken zu können.

@haggholm gibt es einen Grund, ts-ignore gegenüber public metadata!: IEncryptedJSONContainer vorzuziehen?

@RyanCavanaugh Ignoranz! Ich hatte diese Funktion in der Dokumentation vermisst. Es tut uns leid; bitte ignorieren.

ich möchte zu tun

// @ts-ignore-start
--strick Nullüberprüfungen für eine bestimmte Datei

So sieht das Testen privater Felder und Methoden mit Typoskript aus. Ich habe 6 Zeilen, die dem Ignorieren von Code gewidmet sind. Abscheulich. Lässt meine Augen bluten. Alle Problemumgehungen für das Ignorieren von Blöcken wären sehr willkommen.

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();
    }
});

Nun, ich wollte gerade eine neue Ausgabe hinzufügen, aber ich denke, diese Ausgabe deckt es ab.

@ts-ignore behandelt mehrzeilige und einzeilige Importe unterschiedlich!

Es gibt immer noch viele npm-Module, die keine Typisierungen haben oder ohne NoImplicitAny geschrieben sind.
was zu einem "impliziten beliebigen" Fehler führt, dann werden sie importiert:

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

Also kann ich @ts-ignore verwenden:

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

Aber wenn ich mit Auto-Import und Formatierern wie Prettier arbeite, passiert Folgendes:
(Formatiert von Prettier)

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

Ich kann es beheben mit:

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

oder

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

Aber dann sieht es bei einzeiligen Importen so aus:

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

Ich muss es also so schreiben, weil der automatische Import und die Formatierung zwischen einzeiligem und mehrzeiligem Import wechseln, je nachdem, wie viele Elemente aus dem Modul importiert werden.
Es macht den Zweck des automatischen Imports wirklich zunichte, wenn ich den Importcode manuell ändern muss.

Es wäre gut, nicht bei jedem einzelnen Import ts-ignore-start und ts-ignore-end schreiben zu müssen,
Also: //@ts-ignore für den Import (nicht nur die nächste Zeile) ist meiner Meinung nach etwas, das ts-ignore behandeln sollte. (Oder ein anderes Ignorieren wie: @ts-ignore-block / @ts-ignore-import )

Ich muss bestimmte Fehler in der gesamten Datei unterdrücken:

// @ts-ignore-all TS1206

/*
... rest of the file
*/

In Übereinstimmung mit den Leuten oben, die // @ts-ignore-start und // @ts-ignore-end Kommentare vorgeschlagen haben, um die in diesem Thread erwähnten Anwendungsfälle zu behandeln.

Das ist nett, weil es der aktuellen // @ts-ignore -Direktive sehr ähnlich sieht und es Ihnen erlaubt, alle Fehler in einer Datei zu ignorieren, wenn nur die // @ts-ignore-start -Direktive ganz oben steht.

Es gibt positive Anwendungsfälle für eine Reihe der oben genannten Vorschläge. Ich schlage vor:

@ts-ignore als gegenwärtiges Verhalten
@ts-ignore TSxxx [TSxxx ...] bestimmte Fehler unterdrücken
@ts-ignore-start zu ignorierender Startblock
@ts-ignore-start TSxxx [TSxxx ...] unterdrückt bestimmte Fehler für den Block
@ts-ignore-end Endblock
@ts-ignore-all Fehler für den Rest der Datei unterdrücken
@ts-ignore-all TSxxx [TSxxx ...] unterdrückt bestimmte Fehler für den Rest der Datei

"Spezifische Fehler" können benannte Gruppen ähnlich denen in tsconfig oder benutzerdefinierte Gruppen von TSxxx-Fehlern umfassen.

Ich bin mir nicht sicher über den Wert von Blöcken ignorieren, die importierte Module verschachteln; Meine Präferenz würde ts-ignore-Blöcke innerhalb importierter Moduldateien explizit machen. Aber beim Importieren von Bibliotheken von Drittanbietern kann es Gründe dafür geben, also bin ich hier auf dem Zaun.

die gesuchte .tsignore -Datei

genau wie .npmignore & .gitignore

Es sollte einen Ignorierblock geben. Ich bin beim Puppenspieler-Framework hängen geblieben. In Puppeteer haben Sie die Methode "evaluate", mit der Sie beliebige Skriptblöcke auf einer Seite ausführen können. Dieser beliebige Skriptblock könnte Verweise auf Funktionen enthalten, die auf der Seite verfügbar sind, mit anderen Worten, Funktionsreferenzen wären zur Laufzeit verfügbar.

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

Dies ist äußerst praktisch, wenn Sie mit Teilen von Legacy-Code arbeiten, da es für die Leute weniger schmerzhaft ist, auf TypeScript umzusteigen.

Über

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

Ich habe diesen Vorschlag früher gemacht und möchte die Syntax ändern.
Machen Sie es entweder Start-Stop oder Beginn-Ende
start und end (als Verben) sind keine Antonyme und das würde mich für immer stören, wenn es in Typoskript aufgenommen würde.

Das ist cool bei mir

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

Dringend benötigte Funktionalität.

Warum ist das immer noch nicht möglich? :-(

Ignorieren muss ich auch

+1

+1

Gibt es hierzu Neuigkeiten?

🙏🏻

Und wenn wir es genauso machen, wie wir es normalerweise mit Eslint tun?

/* @ts-disable */

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

/* @ts-enable */

Wie oben erwähnt: Sobald Sie TS-Code generieren (zB mit Swagger), wo zB unbenutzte Vars vorkommen könnten, brauchen Sie dieses Feature.

+1

Ohne //@ts-ignore-file ist eine Migration zu TS nicht möglich

Also ist es, ohne dass es jemand merkt , nicht wahr

@RyanCavanaugh Die Community hat eindeutig ein Bedürfnis danach, gibt es einen Grund, warum dies nicht angesprochen wurde? Danke!

Ich kämpfe gerade damit, da ich nicht einmal damit herumspielen kann, eine Lösung zum Laufen zu bringen, um zu sehen, ob es überhaupt machbar ist, ohne dass Typescript weint und mein Rendering blockiert.

Wir benötigen diese Funktion derzeit.

Wir importieren eine öffentliche Bibliothek, die Knotentypen für einige Funktionen enthält, an denen wir nicht interessiert sind. Daher wäre es schön, // @ts-ignore für einen einzelnen Import zu verwenden, anstatt skipLibCheck zum Ignorieren zu verwenden alle Bibliotheken.

Anfangs mochte ich die Idee von // @ts-ignore-file, aber // @ts-ignore würde aus Gründen der Konsistenz wahrscheinlich besser funktionieren.

Also .... Ich habe #33383 mit Unterstützung für //@ts-nocheck in Typoskript-Dateien geöffnet. Nun, da wir das _TypeScript_-Compiler-Team sind, verstehen wir es selbst nicht wirklich (nicht die wahrscheinlichen Probleme beheben, whaaaat!!?!?) - selbst //@ts-ignore in Typoskript wurde nur zu einem Ding, weil unser Arm verdreht war ein bisschen, also sind wir ... zögerlich ... weitere Unterdrückungsmechanismen hinzuzufügen. Wenn Sie also wirklich der Meinung sind, dass ein so umfassender Unterdrückungsmechanismus erforderlich ist, wäre es nett, wenn Sie dorthin gehen und 👍

@weswigham , Dies ist zwar wahrscheinlich nicht die wichtigste Funktion. Es könnte während der Entwicklung nützlich sein. Genau wie das vorübergehende Kommentieren einiger Codezeilen kann es hilfreich sein, ein Problem an anderer Stelle zu entwickeln und zu isolieren. Ich möchte jedoch eine Warnung erhalten, damit diese Praxis keinen Weg findet, tatsächlich Laufzeitfehler zu verursachen. Vielleicht aktivieren Sie diese Funktion sogar nur für die Entwicklung, aber um beim Build einen Fehler auszulösen.

Da dieses Problem immer noch mit "Warten auf weiteres Feedback" gekennzeichnet ist, hier noch mehr:

Wenn ich schnell Prototypen für neue architektonische Richtungen erstelle, möchte ich dies unter Anleitung von TypeScript tun, um sicherzustellen, dass die neue Architektur funktioniert. Ich möchte jedoch Typfehler in Komponententestdateien vorübergehend ignorieren, nur vorübergehend, während ich experimentiere.

Das Hinzufügen einer Art @ts-ignore- -Kommentar oben in jeder Datei wäre einfach genug.

Ich unterstütze die Notwendigkeit von @ kumar303 : Beim Komponententest ist es vorteilhaft, einige Prüfungen für diesen bestimmten Block / diese bestimmte Datei zu deaktivieren, da es die Behauptungen sind, die diese Fälle abdecken.

@weswigham Sie könnten es hinter ein Compiler-Flag setzen.

Sie könnten es hinter ein Compiler-Flag setzen.

Nicht nötig - es ist in der 3.7 Beta enthalten.

re: https://github.com/microsoft/TypeScript/pull/33383 : @weswigham das ist großartig, danke! Ein wirkungsvoller Anwendungsfall ist hier das vorübergehende Ignorieren der Typüberprüfung in einer Datei, daher schlage ich vor, auch eine Flusenregel zu versenden, die fehlschlägt, wenn man vergisst, @ts-nocheck zu entfernen

Ich habe ein Problem mit Gatsby, wo eine statische graphQL-Abfrage in .jsx -Dateien funktioniert, aber nicht in .tsx -Dateien. Ich denke, dieser Vorschlag könnte eine akzeptablere Lösung sein. (Ausgabe hier https://github.com/AdamLeBlanc/gatsby-plugin-ts-loader/issues/5)

Hey!
Wurde die vorgeschlagene Lösung umgesetzt?

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

Ich denke, es wäre sehr vorteilhaft. Ich hätte nichts dagegen, daran zu arbeiten.

Wir haben Unterstützung für //@ts-nocheck hinzugefügt, um alle Fehler in einer ganzen Datei in 3.7 zu unterdrücken. Ich denke, dass die Unterdrückung auf Zeilen- und Dateiebene die meisten Anforderungen ohne viel Aufhebens erfüllen kann. Wenn Sie einen ausreichend großen Block in einer markierten Datei haben, der deaktiviert werden sollte, deaktivieren Sie vielleicht einfach die Überprüfung für die gesamte Datei oder, sollte dies unangenehm sein, extrahieren Sie den nicht markierten Teil in seine eigene Datei und deaktivieren Sie die Überprüfung für diese Datei oder, falls dies nicht möglich ist, Unterdrücken Sie jede Zeile mit einem tatsächlichen Problem? Ein ts-ignore soll ein einzelnes Problem ignorieren, während ein ts-nocheck eine einzelne Datei ignorieren soll - eine bereichsbasierte Unterdrückung wird also in keiner Weise einer bestimmten Einheit zugeordnet scheint irgendwie schlimmer zu sein (da es nicht einem einzelnen Problem oder einer einzelnen Ursache zugeordnet werden kann, die Sie unterdrücken). Zumindest ohne fehlercodespezifische Unterdrückung fühle ich mich mit bereichsbasierten Unterdrückungen nicht besonders wohl.

Zumindest würde ich eine einzelne Unterdrückung ( //@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 ) am Anfang der Datei oder einzelne Unterdrückungen ( //@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 ) für jede einzelne schlechte Sache (tm) bevorzugen. Ich kann mir um mein Leben kein überzeugendes, prinzipielles Beispiel einfallen lassen, bei dem es erlaubt sein sollte, bestimmte _Bereiche_ des Codes zu deaktivieren (im Gegensatz zu Dateien, die eine klare Migrationsstrategie-basierte Argumentation hatten), außer "mehrere aufeinanderfolgende Unterdrückungen lassen meine Augen bluten", wofür ich _null_ Sympathie habe, da wir grundsätzlich der Meinung sind, dass Sie überhaupt keine Unterdrückungen in TypeScript verwenden sollten. Wenn es sich um ein Typproblem handelt, können Sie es auswerfen (deshalb gibt es any , Casting und abgekürzte Moduldeklarationen). Wenn es sich um ein Syntaxproblem handelt, ist alles schrecklich und wir werden sowieso kaputt gehen, also werden Unterdrückungen nichts bewirken (Unterdrückungen wirken sich nicht auf Parsing-Fehler aus).

Danke für //@ts-nocheck , aber das löst nicht das Problem der Deaktivierung der Prüfung auf Codeblock:

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

// @ts-nocheck

Ich habe einen interessanten Anwendungsfall.

Wir haben ORM in Typescript erstellt oder besitzen, das Eichel verwendet, um Anweisungen in unsere DDL zu kompilieren.

Um eine Where-Abfrage durchzuführen, müssen wir ihr Scope-Variablen übergeben:

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

Das funktioniert einfach nicht, weil: Property 'id' does not exist on type 'xxx'

Wenn ich es in @ts-ignore-start einpacke, wird es so funktionieren:

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

Aber wenn das Formatierte vorbeikommt und anfängt, Zeilenumbrüche hinzuzufügen:

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

Es funktioniert nicht mehr.

Das geht einfach nicht, weil:

Das ist genau die Art von Fehler auf Typebene, für die Sie einfach einen as any Cast (oder in jsdoc /** <strong i="8">@type</strong> {any} */(expr) ) für den/die Zugriff(e) haben sollten, wenn Sie ihn wirklich unterdrücken möchten.

//@ts-nocheck funktioniert nicht für mein Winkelprojekt, aber //@ts-ignore tut es. Diese Ausgabe für Microsoft begann im Jahr 2017. 2017! Beeindruckend...

3 Jahre jetzt und keine Lösung. Es überrascht nicht, dass viele JavaScript-Entwickler nicht zu Typoskript wechseln wollen

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

Kombinierbar mit: #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 das ist nicht tslint.

Gibt es Pläne, dies umzusetzen?

// @ts-nocheck
ist derzeit die einzige Möglichkeit :(

Ein weiterer Anwendungsfall, der hier berücksichtigt werden sollte ...

Ich bin Code, der eine Reihe von TypeScript-Codes aus einer internen Markup-Sprache generiert, die einige grundlegende Kontrollabläufe und Bedingungen ermöglicht. Während ich das Verhalten der Codegenerierung kontrolliere, kontrolliere ich nicht die Eingaben, die an den Codegenerator weitergegeben werden (das liegt an den Endbenutzern).

Infolgedessen kann der generierte Code leicht unerreichbaren Code enthalten, oder in einem Fall TS2367, da möglicherweise verschachtelter Code vorhanden ist, der einen Wert gegen eine Enum-Konstante testet und dann innerhalb dieses Blocks eine weitere Prüfung dieser Variablen gegen eine andere Enum-Konstante enthält. Zum Beispiel:

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

Mit handgeschriebenem Code lässt sich dieses Muster leicht beheben und vermeiden. Bei der Codegenerierung liegt es jedoch an meinen Benutzern (Entwicklern, Sie kennen den Typ!), keine Eingaben zu machen, die unnötigerweise auf unmögliche Werte testen.

Ich möchte die Typüberprüfung nicht direkt deaktivieren, aber ich habe keinen anderen Mechanismus, um den vom Code generierten Code aufgrund dieses Fehlers zu verbrauchen. Idealerweise würde ich diesen einen Fehler für alle Code-generierten Dateien unterdrücken, aber alle anderen Typprüfungen beibehalten.

So wie es ist, habe ich keine andere Lösung als das Deaktivieren aller Typprüfungen. An diesem Punkt bekomme ich nicht viel Wert aus TypeScript gegenüber reinem JavaScript

Sind Sie im Ernst? Dies ist immer noch ein offenes Problem und nicht in TS4 implementiert? 🤦🏽

@ivnnv Sie können // @ts-expect-error in TS 3.9 verwenden, siehe hier

@ndraiman @ts-expect-error funktioniert für einzelne Zeilen, aber nicht für Blöcke , daher müssen immer noch viele davon platziert werden, wenn man "einen Block ignorieren" möchte.

Hier noch ein Feedback für dich:

Was brauchst du noch? Was muss die Community tun, um diese Funktionalität zu erhalten?

Der beste Anwendungsfall dafür ist die Alternative zum Schreiben any auf jeden einzelnen Typ, den man erstellt. Sie haben vielleicht kein Verständnis für Ästhetik (was sich zweifellos auf Stimmung und Produktivität auswirkt), aber es sollte nicht schwer sein, einfach eine Alternative zu haben, die den allgemeinen Erwartungen entspricht.

Menschen haben unterschiedliche Ansichten darüber, was akzeptabel ist und was nicht.

Für manche Leute ist es zu zeitaufwändig und schränkt den Flow-Zustand ein, in dem sich Menschen befinden können, während sie alltägliche Dinge wie das Portieren von Code tun.
Ich finde es ärgerlich und seltsam, dass ich keinen ignorierten Codeblock haben kann, sondern ihn stattdessen mit any -Umwandlungen verunreinigen muss, was sich oft nachteilig auf die Lesbarkeit auswirkt (bis die richtigen Typen vorhanden sind). Ständig einen neuen Kommentar schreiben oder sich ablenken zu müssen, _nur weil jemand den Vorteil des Ignorierens von Codeblöcken nicht sieht, ist aus meiner Sicht nicht in Ordnung.

BEISPIEL:

Einer portiert ein Projekt von JS zu TS, während das andere Projekt von einem Drittanbieter entwickelt wird.

Die Syntax und Regeln, die im portierten Projekt befolgt werden, können entweder alt sein, z. B. es2015, oder zugunsten einer klareren Syntax und weniger Code usw. veraltet sein.

Beim Portieren dieses Projekts kann ein Teil des Codes möglicherweise sehr einfach auf TypeScript portiert werden. Dennoch stößt man unvermeidlich auf z. B. halb durchdachte Booleans und Funktionen mit willkürlichem Verhalten, die entweder mehr Kontext benötigen oder einige Zeit darüber nachgedacht werden müssen, um ihre Typen zu erstellen.

Es wäre so großartig, die Überprüfung einer Funktion oder eines Codeblocks in einer Datei zu beenden, während sie repariert wird. Das Ignorieren eines Codeblocks würde es einem ermöglichen, sich schnell in den Bereichen zu bewegen, die man kennt und mit denen man vertraut ist, und bestimmte Teile für später aufzuheben.

Mein Arbeitsablauf, wenn ich JavaScript nach TypeScript portieren muss (und der Code, nun ja, unterdurchschnittlich ist):

1. Kopieren Sie den Code aus der .js- in die .ts-Datei.
2. Prüfen Sie, ob TS anhand der Verwendung irgendwelche Typen ableiten kann
3. Verstehen Sie Typen manuell anhand der Verwendung
4. Erkenne, dass Fehler der Fluch meiner Existenz sind
5. Versuchen Sie, Fehler auszukommentieren, wodurch die Anzahl der Zeilen in der Datei verbessert wird, manchmal x3 ESLlint + TS (mehr ist besser?)
6. Entfernen und fügen Sie oben // @ts-check hinzu, während Sie den Rest der Dateien sorgfältig bearbeiten und weitere Typen hinzufügen.

Wenn wir Blöcke ignorieren könnten:

1. Code von .js nach .ts kopieren
2. Prüfen Sie, ob TS anhand der Verwendung irgendwelche Typen ableiten kann
3. Verstehen Sie Typen manuell anhand der Verwendung
4. // @ts-ignore-enable ... // @ts-ignore-disable individuelle Funktionen & lästige Code-Blöcke
5. Entkommentiere Blöcke, wenn ich zu ihnen komme, und füge Typen hinzu

Entscheiden Sie selbst, was Ihnen am sinnvollsten erscheint. Das Gleiche gilt, wenn Sie JS auf ein Projekt mit viel mehr ESLint-Regeln portieren, und Sie müssen die meisten Dinge umgestalten.

Ich wünschte, wir könnten es so machen, wie es in ESLint möglich ist, und /* eslint:disable */ ... /* eslint:enable */ in TypeScript verwenden.

PS Ich habe gerade festgestellt, als ich diesen Kommentar überprüft habe, dass ich mehr als 20 Minuten damit verbracht habe, eine Erfahrung zu sammeln, nach der ich (und viele andere) seit 2017 gesucht haben, nur um ein bald 3 Jahre altes offenes Problem zu kommentieren.

@weswigham @RyanCavanaugh

Erinnerung :+1:

Wird dafür den Erstgeborenen geben

@agusterodin Dein Opfer zieht die Aufmerksamkeit des Bösen auf sich.....

Okay, es passiert tatsächlich nichts, außer dass ich nur eine einfache PR gebe :)

Allerdings stimme ich persönlich der Meinung des TS-Teams stark zu -- diese Funktion ist böse, Sie sollten immer versuchen, die Verwendung @ts-ignore zu vermeiden, nicht @ts-ignore-enable (oder @ts-ignore-start , wie auch immer).
Aber manchmal sagt das Sprichwort drinking posion to satisfie thirst , ich weiß, es ist eine schlechte Wahl, aber es ist einfach nötig.

Bearbeiten: Erklären und Beispiele hinzufügen.
Dieser PR fügt zwei Direktiven ts-ignore-enable und ts-ignore-disable hinzu.

1. Wenn Sie nur ts-ignore-enable verwenden, wird der Rest ignoriert.

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

1. Sie könnten mehrmals dieselben Anweisungen hinzufügen, aber sie funktionieren nur einmal.

// @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 allein verwendet werden könnte, würde nichts passieren.

2. @ts-expect-error würde in der ignorierten Region nicht funktionieren

// @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. keine Regionsbezeichnung, sie sind nur ein Kommentar.

// @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.

In einer perfekten Welt müssten wir die Typensicherheit nicht ignorieren, oder? :sweat_smile:
Ich brauche es, wenn ich fantastische Arbeiten kopiere, z. B. Beispiele und Starter, sogar die gelegentliche SO-Antwort, die nicht getippt oder getippt ist, wie ich es möchte. Hauptsächlich, um es in meinem typsicheren Code zu haben, der meinen Einstellungen folgt. Ich verwende nur sehr strenge Einstellungen und muss deshalb oft eine Funktion oder eine Logik neu schreiben. Es liegt nicht daran, dass ich diesen Codeblock weiterhin ignorieren möchte, das würde keinen Sinn machen.

Das Ignorieren eines Codeblocks ist eine Annehmlichkeit, die mir vollkommen vernünftig erscheint, da ich immer noch jede Zeile in einem Block @ts-ignore kann.

Ich verstehe die möglichen Auswirkungen, die dies für Leute haben könnte, die I'll just ignore this because it's easier gehen. Aus meiner Sicht trinkt jeder, der Block-Scope Ignorieren zu drink poison to satisfy their thirst verwenden könnte, bereits Gifttropfen mit @ts-ignore .

Jetzt, da Sie @ts-nocheck in .ts -Dateien ausführen können, schlage ich vor, @ts-check auch in .ts -Dateien zuzulassen, damit wir die Typprüfung ein- und ausschalten können:

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

Dazu muss nicht definiert werden, was ein "Codeblock" ist. Sie können die Typprüfung von - bis zu jeder Zeile starten und stoppen.

UPDATE Ich habe mich geirrt, siehe https://github.com/microsoft/TypeScript/pull/40267#issuecomment -713840095 für die Korrektur.

Beim Versuch, eine App mit styled-components zu TypeScript zu migrieren, stieß ich auf ein Problem, bei dem @ts-ignore (aus irgendeinem Grund) nicht über Vorlagenzeichenfolgen verwendet werden kann. Es hätte mit einem Ignore-Block gelöst werden können.

Beispiel für den TS-Fehler, den ich zu ignorieren versuchte:

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

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

Als extra Hinweis: Ich kann in meinem TS-Projekt keine casten, ich erlaube keine Typen. Was ist denn die Empfehlung?

@weswigham Was denkst du über Flow-State und Produktivität im Zusammenhang mit Ästhetik? Scheinbar hast du kein Verständnis für blutende Augen; Aber haben Sie irgendwelche Vorstellungen von Produktivität, Portierung von Code und den von mir beschriebenen Prozessen? Siehst du immer noch _überhaupt_ keinen Nutzen, nachdem du meinen Kommentar in Betracht gezogen hast, und im Zusammenhang damit, produktiver zu sein? Ich habe auch einige reale Situationen beschrieben, in denen man den Blockbereich ignorieren müsste. Außerdem, inwiefern ist diese Funktionalität nicht vergleichbar mit ESLint und der Funktionalität, die wir dort erwarten?

Es ist wissenschaftlich erwiesen , dass weniger Unterbrechungen die Produktivität steigern und die Effizienz steigern; Das Ignorieren des Blockbereichs würde weniger Unterbrechungen beim Portieren von Code ermöglichen. Ist dem TS-Team nicht klar, dass „wir grundsätzlich der Meinung sind, dass Sie überhaupt keine Unterdrückungen in TypeScript verwenden sollten“. ist eine Meinung, die auf dem Leben und Atmen von TypeScript basiert und dass Menschen in der realen Welt schlecht geschriebenen Code auf andere Codebasen portieren müssen, mit mehr Typsicherheit und anderen Linting-Regeln; In solchen Situationen macht es keinen Sinn, dass Sie eine Datei oder eine Zeile ignorieren können, aber nicht den Codeblock, den Sie gerade importiert haben.

Für mich scheint es, als würdest du Utopie anstreben, während du die Realität ignorierst. @sandersn Du bist auf keinen meiner Punkte eingegangen und hältst die alte Antwort über neuere Diskussionen in dem Fall. Sie geben auch an, dass es nicht implementiert werden sollte, es sei denn, das Team beschließt etwas anderes. In diesem Fall: Problem schließen?

Das Team muss entweder eine Entscheidung treffen oder ein eindeutig gewünschtes Feature implementieren.

Das Thema in der Schwebe zu halten, macht keinen Sinn.

Es tut mir leid, dass wir Ihnen nicht die Endgültigkeit geben können, die Sie brauchen, aber die Realität ist, dass „vielleicht später“ eine Antwort ist, mit der Sie lernen müssen, zu leben. Eine bestimmte Funktion kann nicht morgen in das Produkt eingebaut werden, und für Funktionen, die in unsere Designparameter fallen, gibt es Tausende von derzeit offenen Vorschlägen, die um unsere Fähigkeit konkurrieren, sie dem Produkt auf ergonomische Weise hinzuzufügen. nützlich, stabil und zukunftsorientiert.

Wir priorisieren Dinge basierend auf aktuellem Feedback, dem Stand aktueller Lösungen und Problemumgehungen, dem Überwiegen dieser Szenarien, Tools und hundert anderen Faktoren. Dinge, die jetzt keine hohe Priorität haben, können später eine hohe Priorität bekommen. Das ist die Natur von „vielleicht später“, und ich denke, das ist eine genaue Darstellung dessen, wo dieser Vorschlag steht. Die Entscheidung hier ist vorerst, das Feedback weiter zu überwachen und zu verstehen, auf was die Leute stoßen, was dazu führen könnte, dass diese Funktion eine höhere Priorität hat als jede andere Funktion, die wir als nächstes hinzufügen könnten, von denen Hunderte um Aufmerksamkeit konkurrieren.

Der Ton hier geht ehrlich gesagt in Richtung Feindseligkeit und persönlich zu sprechen, zu einem Ultimatum gedrängt zu werden, ist einem konstruktiven Gespräch nicht förderlich, das uns hilft zu verstehen, wo dies einen Mehrwert darstellt, der seine Komplexität im Vergleich zu den Alternativen übertrifft.

Es tut mir leid, dass ich ein Ultimatum gestellt habe. Ich war ziemlich verärgert, als ich Aktivitäten in Richtung PR sah, aber keine zu diesem Thema. Ich stimme zu, dass mein vorheriger Kommentar keinen konstruktiven Beitrag leistet.

Ich kann akzeptieren, dass dieses Problem möglicherweise warten muss. Ich habe Feedback gegeben und gefragt, welches andere Feedback notwendig ist, um der Lösung näher zu kommen, aber ich habe keine Antwort erhalten. Es scheint, so ärgerlich es auch sein mag, dass mein eher unkonstruktiver Kommentar das war, was ich tun musste, um _etwas_ Antwort vom Team zu bekommen.

Es scheint immer noch, dass kein wirklicher Fortschritt in Richtung einer Ausgabe mit über 700 positiven Reaktionen, die mehrere Jahre alt ist, gemacht wurde. Ich glaube nicht, dass es schneller gehen sollte, aber es scheint, als wäre das Team nicht daran interessiert, diese Funktion zu erkunden, da die Mitglieder persönliche Meinungen dagegen haben. Ich verstehe all diese Dinge vollkommen. Darum geht es mir hier aber nicht. Ich möchte ein Gespräch in Gang bringen, aber ich werde ignoriert.

Ich möchte gerne wissen, dass mein Feedback berücksichtigt und entsprechend seiner Art beantwortet wird. Es ist keine große Störung im Feature-Set, was durch die aktive PR gezeigt wird, die in kurzer Zeit hochgepeitscht wurde. Alles ist einsatzbereit, die Leute reagieren immer wieder positiv auf die Lösung dieses Problems mit einer Funktion zum Blockieren von Ignorieren, und ich mischte mich ein und fragte, was die Community tun muss, um diese Funktion zu erhalten. Ich bin mit einigen der vom Team vorgebrachten Punkte absolut nicht einverstanden und habe dagegen argumentiert, es wurde eine PR gemacht und ein Kommentar abgegeben, der besagt, dass sich nichts ändern wird , wenn wir unsere Meinung nicht ändern.

Da kommt mein Frust hoch. Sie möchten ein fertiges Feature ignorieren, weil keine Änderungen an einer Entscheidung eines Teammitglieds vorgenommen wurden, und mein eigenes Feedback und das Feedback anderer Leute völlig ignorieren.

Es scheint, dass wir keine Änderungen in dieser Angelegenheit sehen werden, es sei denn, jemand im Team entscheidet _in seinem Einvernehmen_ anders. Das erfordert nicht mehr Feedback aus der Community, oder? Deshalb habe ich zu Unrecht das Ultimatum gestellt.

Ich habe mehrere Argumente gegen die Punkte von @weswigham vorgebracht , einige Beispiele gegeben und warte ehrlich gesagt immer noch auf eine Art Antwort darauf. Das einzige, was zu helfen schien, war sichtbar verärgert und unkonstruktiv zu sein.

Wie bewegen wir uns von hier fort? Welches Feedback wünscht sich das Team? Es scheint ein persönliches Problem zu sein, das sich hinter „Wir priorisieren Dinge basierend auf aktuellem Feedback, dem Stand aktueller Lösungen und Problemumgehungen, dem Übergewicht dieser Szenarien, Tools und hundert anderen Faktoren“ verbirgt. da mehrere Leute versucht haben, Feedback zu geben, ohne _überhaupt_ eine Antwort vom Team.

Ich möchte wiederholen, dass ich verstehe, dass dies möglicherweise keine hohe Priorität hat, wenn wir die Meinungen der Menschen von diesem Thema ablenken. Gleichzeitig ist das Feature bereit für die Implementierung, und es wurden Argumente vorgebracht. Was jetzt benötigt wird, ist, dass das Team eine Entscheidung/Antwort trifft (nicht unbedingt etwas umsetzt) ​​und diese öffentlich macht. Wenn dies nicht erforderlich ist, sagen Sie mir bitte, was erforderlich ist oder wie man dazu beitragen kann, die Priorität für _irgendein_ Feature oder Problem für TypeScript zu erhöhen, insbesondere aber für dieses.

Ein weiterer Anwendungsfall für Multiline ( @ts-ignore-start+@ts-ignore-end ) oder Inline (wie /* @ts-ignore */ ) @ts-ignore .
Umfeld:

• "noUnusedParameters": true
• ESLint require-jsdoc -Regel aktiviert.
• Code ähnlich dem folgenden (vereinfachtes Beispiel):

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...
}

Für die beschriebene Situation gibt TypeScript die folgende Warnung aus: 'settings' is declared but its value is never read.(6133) .
Es ist möglich, die Warnung zu unterdrücken, indem man @ts-ignore nach dem Ende des Dokumentationskommentars hinzufügt:

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

Aber danach wird sich ESLint über Missing JSDoc comment beschweren.
Die Lösung lautet also:

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

Was umständlich und hässlich ist.

@RyanCavanaugh @weswigham @sandersn

Eine monatliche Erinnerung, dass dies etwas ist, was die Community mit dem TypeScript-Team weiter besprechen möchte. Es gibt viel Unterstützung und was derzeit fehlt, ist eine Reaktion des Teams. Ich verstehe, dass es viele Überlegungen gibt, und TypeScript voranzutreiben, ist keine leichte Aufgabe. Dinge brauchen Zeit. Da es keine Antwort darauf gibt, wie wir diesen Vorschlag weiter vorantreiben und direktere Maßnahmen ergreifen können, werde ich regelmäßig eine Erinnerung wie diese erstellen. Ich gebe nicht auf, bis eine Entscheidung getroffen wurde, und das Kommentieren scheint Auswirkungen zu haben (allerdings meistens, wenn es sich um ein !@# handelt).

Nachdem diese Jahre vergangen waren, obwohl ich ursprünglich ausgeflippt war, dass diese Funktionalität nicht vorhanden ist, habe ich persönlich ein wenig darüber nachgedacht ... Wenn es einen riesigen Haufen von @ts-ignore gibt, merkt man vielleicht schon, dass etwas nicht stimmt mit Ihrem Code und verbringen Sie etwas Zeit damit, Ihre Typen zu verbessern. Wir alle sind manchmal ziemlich faul und wollen insgesamt Geschwindigkeit, aber derzeit ist es oft einfacher, einige richtige Typen herauszufinden, als mehrere @ts-ignore in große Codebündel zu kopieren und einzufügen. Wenn dieses Gleichgewicht der Unannehmlichkeiten unterbrochen wird, werden viele von uns bequemerweise @ts-ignore-enable missbrauchen, was die Gesamtqualität aller kleinen Open-Source-Projekte hier und da nur beeinträchtigen könnte.

Übrigens, obwohl wir sehen, dass es viele 👍 Reaktionen zu diesem Thema gibt, - es könnte voreingenommen sein, weil viel mehr Menschen sich ohne diese Funktion völlig wohl fühlen, während sie schweigen, weil sie nicht hier sind.

@JerryGreen Unter Bezugnahme auf meine älteren Kommentare habe ich genau dasselbe gesagt. Mit dem Zusatz, dass die Leute dies bereits mit der Ignorieren-Funktion tun. Es gibt keinen Grund, ein bisschen Gift zu implementieren, während man behauptet, es sollte _none_ geben .

Entfernen Sie entweder die @ts-ignore -Funktionalität oder machen Sie sie vollwertig. Es gibt viele Argumente dafür, und Leute, die schlechten Code schreiben, werden weiterhin @ts-ignore verwenden, was genauso schlecht ist wie eine Funktion zum Ignorieren von Blöcken, sie sind genau dasselbe - außer dass das Ignorieren von Blöcken weniger visuell störend ist.

Die Community benötigt noch eine Antwort vom TypeScript-Team.

@JerryGreen Unter Bezugnahme auf meine älteren Kommentare habe ich genau dasselbe gesagt. Mit dem Zusatz, dass die Leute dies bereits mit der Ignorieren-Funktion tun. Es gibt keinen Grund, ein bisschen Gift zu implementieren, während man behauptet, es sollte _none_ geben .

Entfernen Sie entweder die @ts-ignore -Funktionalität oder machen Sie sie vollwertig. Es gibt viele Argumente dafür, und Leute, die schlechten Code schreiben, werden weiterhin @ts-ignore verwenden, was genauso schlecht ist wie eine Funktion zum Ignorieren von Blöcken, sie sind genau dasselbe - außer dass das Ignorieren von Blöcken weniger visuell störend ist.

Die Community benötigt noch eine Antwort vom TypeScript-Team.

Einige spezielle Szenarien müssen immer noch @TSignorieren. Beispielsweise hängt der CDN-Import nicht von node_ The ab. TS-Datei ist im Modulszenario nicht vorhanden

@L-Hknu Danke für die Klarstellung. Die Leute verwenden es, da sie sowieso Ignorieren mit ESLint verwenden.

Die Ignore-Funktionalität ist nicht in Kontexten verboten, außer dort, wo sie für die Funktionalität benötigt wird. Das sagt mir, dass es in Ordnung ist, es zu verwenden, um Code zu ignorieren.

Ich kann immer noch nicht begründen, warum es kein Blockieren geben sollte, da es die meiste Zeit auf die gleiche Weise verwendet wird.

Ich habe die Konvertierung in Typen für einigen Open-Source-Code aufgegeben, weil der Fortschritt der Konvertierung mit Block-Ignorieren so viel komfortabler gewesen wäre. Ich brauche es nicht, aber ich denke, viele Leute werden mit dem Tippen einen Fuß in die Tür bekommen; Darüber hinaus würden viele Menschen höchstwahrscheinlich effizienter zu Konvertierungen beitragen, insbesondere wenn man bedenkt, wie unterschiedlich die Ästhetik zwischen Block- und Kommentaren in jeder Zeile ist.

Mein größter Anwendungsfall für diese Implementierung wären Pakete von Drittanbietern, die keine Typoskript-Unterstützung haben, und ich müsste einige ihrer Verwendungen ignorieren.

@L-Hknu Danke für die Klarstellung. Die Leute verwenden es, da sie sowieso Ignorieren mit ESLint verwenden.

Die Ignore-Funktionalität ist nicht in Kontexten verboten, außer dort, wo sie für die Funktionalität benötigt wird. Das sagt mir, dass es in Ordnung ist, es zu verwenden, um Code zu ignorieren.

Ich kann immer noch nicht begründen, warum es kein Blockieren geben sollte, da es die meiste Zeit auf die gleiche Weise verwendet wird.

Ich habe die Konvertierung in Typen für einigen Open-Source-Code aufgegeben, weil der Fortschritt der Konvertierung mit Block-Ignorieren so viel komfortabler gewesen wäre. Ich brauche es nicht, aber ich denke, viele Leute werden mit dem Tippen einen Fuß in die Tür bekommen; Darüber hinaus würden viele Menschen höchstwahrscheinlich effizienter zu Konvertierungen beitragen, insbesondere wenn man bedenkt, wie unterschiedlich die Ästhetik zwischen Block- und Kommentaren in jeder Zeile ist.

Es sieht aus, als wäre es fertig
#40267