besoin de ça lol

Le cas d'utilisation actuel de cette fonctionnalité est un test unitaire qui traite des espaces. Nous avons la règle "no-trailing-whitespace" activée dans notre base de code pour une bonne raison, mais ne pas pouvoir la maîtriser au niveau du bloc signifie que nous ne pouvons pas facilement tester les espaces blancs de fin et les retours chariot à l'aide d'une chaîne de modèle ES6 .

un de mes cas d'utilisation pour utiliser le groupement personnalisé _ a.k.a partial import _ dans mathjs

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

Je voudrais ignorer les erreurs pour un fichier entier. J'ai hérité du code ES6 JS que j'aimerais transpiler vers ES5 mais je dois utiliser Babel pour le moment. Ce serait bien de simplement renommer le fichier en .ts et de le transpiler avec TS.

@ptallett vous pouvez simplement compiler les fichiers .js en utilisant allowJs et l'inclure dans la compilation. Par défaut, nous n'émettons pas d'erreurs sur les fichiers .js à moins que le fichier ait un commentaire // @ts-check en haut, ou que vous activiez checkJs .

J'aimerais toujours cette fonctionnalité, je suis assis dans un fichier de test, il a l'extension .ts, donc je peux importer et voir facilement quels paramètres vont où, et le compiler dans un répertoire à côté des fichiers src est génial pour mon cas d'utilisation .

La plupart de mes lignes sont maintenant rouges, car j'essaie délibérément d'exclure certains paramètres ou de donner à la fonction un type différent de celui qu'elle prend à l'origine, et je m'attends à ce qu'une erreur soit générée, car je la vérifie également lors de l'exécution.

Ce serait bien de ne pas avoir un tas de lignes rouges partout. :)

Y a-t-il une mise à jour à ce sujet ou quelqu'un a-t-il trouvé un bon moyen de le faire?

Utiliser lodash & surtout lodash/fp avec TypeScript est si pénible, et même avec les dernières versions de lodash & @types/lodash vous pouvez vous retrouver avec des messages d'erreur très cryptés.

Si nous pouvons avoir un @ts-ignore-block qui ignore les erreurs pour le bloc suivant, ce serait formidable pour des cas d'utilisation comme celui-ci où _vous savez ce que vous faites_ :-)

Je travaille avec du code hérité avec de nombreuses variables de portée globale, et écrire @ts-ignore sur chaque ligne est devenu fastidieux, des mises à jour à ce sujet ?

Cherche également une mise à jour sur cette demande. Merci!

Ce serait également très important pour ce que je fais (à savoir la vérification du type des fonctions de rendu de modèle Vue générées, ce qui nécessiterait de désactiver des inspections spécifiques pour un bloc de code.)
Parallèlement à ce problème, # 19139 serait très important, car en particulier lors de l'application à de grandes parties de code, vous ne voudrez désactiver que des inspections spécifiques.

avec la suppression du fichier trou, cela pourrait être ajouté aux éditeurs comme vs code pour enregistrer dans les paramètres de l'espace de travail ou autres.

Besoin aussi de ça. Je génère automatiquement un fichier ts entier avec des types pour mon schéma GraphQL en utilisant graphql-code-generator et il y a une importation superflue déclenchant noUnusedLocals.

/* tslint:désactiver */

code

/* tslint:enable */

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

Peut être combiné avec : 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 ce n'est pas tslint.

Parfois, pendant que je déplace des éléments et que je refactorise, je veux temporairement ignorer tout le fichier (c'est-à-dire ne pas le compiler), sans jouer avec les options CLI.

Le plus rapide/le plus simple est un drapeau en haut du fichier :

// @ts-ignore-file

@ lonix1 Votre cas d'utilisation est couvert par :

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

Vous n'êtes pas obligé d'utiliser la partie // @ts-ignore-end . De nombreux outils anti-peluches fonctionnent de cette façon.

@mgol Je ne veux pas faire dérailler ce fil... mais j'ai essayé votre suggestion - merci ! - et ça n'a pas marché pour moi. J'ai assemblé les lignes en haut du fichier et j'ai également essayé l'une en haut et l'autre en bas.
Quelqu'un d'autre peut-il le faire fonctionner?

@ lonix1 Je voulais dire que la proposition de @Blanen fonctionnerait également pour vous, nous n'avons pas besoin de TypeScript pour implémenter à la fois // @ts-ignore-start + // @ts-ignore-end et // @ts-ignore-file , implémentant // @ts-ignore-start + // @ts-ignore-end suffiraient. Ce n'est pas implémenté, c'est pourquoi ce problème est toujours ouvert.

@DanielRosenwasser , cela ne fonctionnerait que lorsque les fichiers ts seraient stockés dans un autre dossier lors de la construction. lorsque le projet est configuré pour placer les fichiers js à côté des fichiers ts, il ne le fera pas. Les fichiers js seront-ils également "compilés", par exemple transformés en es5 ? Lors du transport de code hérité, cela serait vraiment utile.

Besoin de cette fonctionnalité.

Cas d'utilisation:

TypeORM s'attend à ce que nous créions des classes d'entités DB qui ont des colonnes qui peuvent ou non être nullables. De nombreuses colonnes (donc) ne sont pas nullables… et doivent donc être traitées, sauf dans la définition de la classe, comme si les propriétés appartenaient inconditionnellement à certains types définis. Cependant, Typescript nous oblige à définir chaque colonne comme étant fortement typée. Par conséquent, nous nous retrouvons avec un grand nombre d'entités telles que :

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

Chaque colonne est obligatoire et (donc) certaine de contenir une valeur, mais en raison du fonctionnement de TypeORM, chaque propriété doit être définie de manière à ne pas avoir d'initialiseur. Il serait extrêmement pratique de pouvoir supprimer ce problème particulier, dérivé de l'ORM/spécifique, pour une classe entière (donc/ou fichier).

@haggholm aucune raison de préférer ts-ignore à public metadata!: IEncryptedJSONContainer ?

@RyanCavanaugh Ignorance ! J'avais raté cette fonctionnalité dans la documentation. Pardon; Merci d'ignorer.

je voudrais faire

// @ts-ignore-start
--strick null vérifie, pour un fichier particulier

C'est ce à quoi ressemblent les champs privés et les méthodes unittesting avec tapuscrit. J'ai 6 lignes dédiées à ignorer le code. Affreux. Me fait saigner des yeux. Toute solution de contournement pour l'ignorance des blocs serait très appréciée.

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

Eh bien, j'étais sur le point d'ajouter un nouveau problème, mais je suppose que ce problème le couvre.

@ts-ignore gère différemment les importations multilignes et monolignes !

Il y a encore beaucoup de modules npm qui n'ont pas de typage, ou sont écrits sans NoImplicitAny,
qui entraînent une erreur "tout implicite", puis ils sont importés :

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

Je peux donc utiliser @ts-ignore :

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

Mais lorsque je travaille avec l'importation automatique et des formateurs comme Prettier, cela se produit :
(Formaté par Prettier)

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

Je peux le réparer avec :

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

ou

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

Mais ensuite, cela commence à ressembler à ceci sur les importations d'une seule ligne :

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

Je dois donc l'écrire comme ça parce que l'importation automatique et la mise en forme changeront entre l'importation sur une seule ligne et sur plusieurs lignes en fonction du nombre d'éléments importés depuis le module.
Cela va vraiment à l'encontre du but de l'importation automatique si je dois modifier le code d'importation manuellement.

Ce serait bien de ne pas avoir à écrire ts-ignore-start et ts-ignore-end sur chaque importation,
Donc : //@ts-ignore pour l'importation (pas seulement la ligne suivante) est à mon avis quelque chose que ts-ignore devrait gérer. (Ou un autre ignorer comme : @ts-ignore-block / @ts-ignore-import )

j'ai besoin de supprimer certaines erreurs dans l'ensemble du fichier :

// @ts-ignore-all TS1206

/*
... rest of the file
*/

En accord avec les personnes ci-dessus qui ont suggéré des commentaires // @ts-ignore-start et // @ts-ignore-end pour gérer les cas d'utilisation mentionnés dans ce fil.

C'est bien, car cela ressemble beaucoup à la directive // @ts-ignore actuelle, et cela vous permet d'ignorer toutes les erreurs dans un fichier avec juste la directive // @ts-ignore-start en haut.

Il existe des cas d'utilisation positifs pour un certain nombre des suggestions ci-dessus. Je propose:

@ts-ignore comme comportement actuel
@ts-ignore TSxxx [TSxxx ...] supprimer des erreurs spécifiques
@ts-ignore-start bloc de départ à ignorer
@ts-ignore-start TSxxx [TSxxx ...] supprimer les erreurs spécifiques pour le bloc
@ts-ignore-end bloc de fin
@ts-ignore-all supprimer les erreurs pour le reste du fichier
@ts-ignore-all TSxxx [TSxxx ...] supprimer les erreurs spécifiques pour le reste du fichier

Les "erreurs spécifiques" peuvent inclure des groupes nommés similaires à ceux de tsconfig ou des groupes d'erreurs TSxxx définis par l'utilisateur.

Je ne suis pas certain de la valeur d'ignorer les blocs imbriqués dans les modules importés ; ma préférence serait les blocs ts-ignore explicites dans les fichiers de module importés. Mais lors de l'importation de bibliothèques tierces, il peut y avoir des raisons à cela, donc je suis sur la clôture ici.

le fichier .tsignore recherché

comme .npmignore & .gitignore

Il devrait y avoir un bloc Ignorer. Je suis resté coincé avec le cadre de marionnettiste. Dans puppeteer, vous avez la méthode "evaluate" qui vous permet d'exécuter un bloc de script arbitraire sur une page. Ce bloc de script arbitraire pourrait contenir une référence à des fonctions disponibles sur la page, en d'autres termes, une référence de fonction serait disponible au moment de l'exécution.

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

Cela sera extrêmement pratique lorsque vous travaillez avec des morceaux de code hérité, ce qui rendra moins pénible pour les gens de passer à TypeScript.

Sur

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

J'ai fait cette suggestion plus tôt et je veux en quelque sorte changer la syntaxe.
Faites-le démarrer-arrêter ou commencer-fin
start et end (en tant que verbes) ne sont pas des antonymes et cela me dérangerait pour toujours si cela entrait dans le tapuscrit.

C'est cool avec moi

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

Fonctionnalité très nécessaire.

Pourquoi n'est-ce toujours pas possible ? :-(

J'ai besoin de bloquer aussi

+1

+1

Une mise à jour pour ceci?

🙏🏻

Et si nous le faisions comme nous le faisons normalement avec eslint ?

/* @ts-disable */

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

/* @ts-enable */

Comme mentionné ci-dessus : dès que vous générez du code TS (par exemple avec swagger) où, par exemple, des vars inutilisés peuvent se produire, vous avez besoin de cette fonctionnalité.

+1

Sans //@ts-ignore-file il est impossible de migrer vers TS

Donc, ce n'est pas vrai sans que personne ne s'en aperçoive

@RyanCavanaugh La communauté en a clairement besoin, y a-t-il une raison pour laquelle cela n'a pas été résolu ? Merci!

Je me bats avec cela en ce moment car je ne peux même pas jouer avec une solution qui fonctionne pour voir si elle est même réalisable sans que Typescript ne pleure et ne bloque mon rendu.

Nous avons actuellement besoin de cette fonctionnalité.

Nous importons une bibliothèque publique qui a des types de nœuds pour certaines fonctions qui ne nous intéressent pas. Il serait donc agréable d'utiliser // @ts-ignore pour une seule importation, au lieu d'utiliser skipLibCheck pour ignorer toutes les bibliothèques.

Au départ, j'aimais // l'idée de @ts-ignore-file, mais // @ts-ignore fonctionnerait probablement mieux pour des raisons de cohérence.

Alors .... J'ai ouvert # 33383 avec le support de //@ts-nocheck dans les fichiers dactylographiés. Maintenant, nous étant l'équipe de compilateurs _TypeScript_, nous ne comprenons pas vraiment nous-mêmes (ne résolvant pas les problèmes probables, quoi !!?!?) - même //@ts-ignore en tapuscrit n'est devenu une chose que parce que notre bras était tordu un peu, donc nous hésitons... à ajouter d'autres mécanismes de suppression. Donc, si vous pensez vraiment qu'un mécanisme de suppression aussi large est nécessaire, ce serait bien si vous pouviez aller là-bas et 👍

@weswigham , bien que ce ne soit probablement pas la fonctionnalité la plus importante. Cela pourrait être utile pendant le développement. Tout comme commenter temporairement quelques lignes de code, cela peut être utile lors du développement et de la tentative d'isoler un problème ailleurs. J'aimerais cependant recevoir un avertissement afin que cette pratique ne trouve pas son moyen de provoquer des bogues d'exécution. Peut-être même activer cette fonctionnalité pour le développement uniquement, mais pour générer une erreur lors de la construction.

Étant donné que ce problème est toujours intitulé "En attente d'autres commentaires", voici plus :

Lors du prototypage rapide de nouvelles directions architecturales, j'aimerais le faire guidé par TypeScript, pour m'assurer que la nouvelle architecture fonctionnera. Cependant, je souhaite ignorer temporairement les erreurs de type dans les fichiers de test unitaire , juste temporairement, pendant que j'expérimente.

Ajouter une sorte de commentaire @ts-ignore- en haut de chaque fichier serait assez facile.

J'appuie le besoin de @ kumar303 : dans les tests unitaires, il est avantageux de désactiver certaines vérifications pour ce bloc/fichier donné, car ce seront les assertions qui couvriront ces cas.

@weswigham Vous pouvez le mettre derrière un indicateur de compilateur.

Vous pouvez le mettre derrière un indicateur de compilateur.

Pas besoin - c'est dans la version bêta 3.7.

re : https://github.com/microsoft/TypeScript/pull/33383 : @weswigham c'est super, merci ! Un cas d'utilisation puissant ici consiste à ignorer temporairement la vérification de type dans un fichier. Je suggère donc également d'envoyer une règle de charpie qui échoue lorsque l'on oublie de supprimer @ts-nocheck

Avoir un problème sur gatsby, où une requête graphQL statique fonctionne dans les fichiers .jsx , mais pas dans les fichiers .tsx . Je pense que cette proposition pourrait être une solution de contournement plus acceptable. (problème ici https://github.com/AdamLeBlanc/gatsby-plugin-ts-loader/issues/5)

Hé!
La solution proposée a-t-elle été mise en œuvre ?

// @ts-ignore-start
// @ts-ignore-fin

Je pense que ce serait très bénéfique. Ça ne me dérangerait pas de travailler dessus.

Nous avons ajouté la prise en charge de //@ts-nocheck pour supprimer toutes les erreurs dans un fichier entier dans la version 3.7. Je pense que la suppression au niveau de la ligne et au niveau du fichier peut englober la plupart des besoins sans trop de problèmes. Si vous avez un bloc suffisamment grand dans un fichier coché qui devrait être décoché, désactivez peut-être simplement la vérification de l'ensemble du fichier ou, si cela est désagréable, extrayez le morceau non coché dans son propre fichier et désactivez la vérification de ce fichier ou, à défaut, supprimer chaque ligne avec un problème réel ? Un ts-ignore est censé ignorer un seul problème, tandis qu'un ts-nocheck est censé ignorer un seul fichier - une suppression basée sur la plage ne correspond en aucun cas à une unité spécifique, donc semble en quelque sorte pire (puisqu'il ne peut pas être mappé à un seul problème ou à une cause première que vous supprimez). Au moins sans suppressions spécifiques au code d'erreur, je ne suis pas particulièrement à l'aise avec les suppressions basées sur la plage.

Moi, au moins, je préférerais une seule suppression ( //@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 ) en haut du fichier ou des suppressions individuelles ( //@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 ) sur chaque mauvaise chose (tm). Je ne peux pas, pour ma vie, trouver un exemple convaincant et fondé sur des principes où des _gammes_ de code spécifiques devraient être autorisées à être décochées (contrairement aux fichiers, qui avaient un raisonnement clair basé sur une stratégie de migration), autre que "l'écriture de plusieurs les suppressions me font saigner les yeux", pour lesquelles j'ai _zéro_ sympathie car, fondamentalement, nous pensons que vous ne devriez pas du tout utiliser les suppressions dans TypeScript. S'il s'agit d'un problème de type, vous pouvez en sortir (c'est pourquoi any , le casting et les déclarations de modules raccourcis existent). Si c'est un problème de syntaxe, tout est horrible et nous serons de toute façon cassés, donc les suppressions ne feront rien (les suppressions n'affectent pas les erreurs d'analyse).

Merci pour //@ts-nocheck , mais cela ne résout pas le problème de désactivation de la vérification du bloc de code :

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

// @ts-nocheck

J'ai un cas d'utilisation intéressant.

Nous avons construit ou possédons ORM dans Typescript qui utilise acorn pour compiler des instructions dans notre DDL.

Pour faire une requête where, nous devons lui passer des variables étendues :

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

Cela ne fonctionne pas simplement parce que : Property 'id' does not exist on type 'xxx'

Si je l'enveloppe dans @ts-ignore-start , cela fonctionnera bien comme ceci :

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

Mais lorsque le formaté arrive et commence à ajouter des sauts de ligne :

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

Cela ne fonctionne plus.

Cela ne fonctionne pas simplement parce que :

C'est exactement le genre d'erreur au niveau du type pour laquelle vous devriez avoir un cast as any (ou, dans jsdoc, /** <strong i="8">@type</strong> {any} */(expr) ) sur le ou les accès, si vous voulez vraiment le supprimer.

//@ts-nocheck ne fonctionne pas pour mon projet angulaire ts mais //@ts-ignore fait. Ce problème pour Microsoft a commencé en 2017. 2017 ! Wow...

3 ans maintenant et aucune solution. Il n'est pas surprenant que les développeurs JavaScript ne veuillent pas passer au tapuscrit

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

Peut être combiné avec : #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 ce n'est pas tslint.

Des plans pour mettre cela en œuvre ?

// @ts-nocheck
est la seule option actuellement :(

Un autre cas d'utilisation à ajouter pour examen ici...

Je suis un code générant un tas de code TypeScript à partir d'un langage de balisage interne qui permet un flux de contrôle de base et des conditions. Bien que je contrôle le comportement de génération de code, je ne contrôle pas les entrées transmises au générateur de code (c'est aux utilisateurs finaux)

En conséquence, le code généré peut facilement avoir un code inaccessible, ou dans un cas TS2367 car il peut y avoir un code imbriqué qui teste une valeur par rapport à une constante enum, puis à l'intérieur de ce bloc contient une autre vérification de cette variable par rapport à une autre constante enum. Par exemple:

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

Avec un code écrit à la main, ce modèle est facile à corriger et à éviter. Avec la génération de code, cependant, il appartient à mes utilisateurs (développeurs, vous connaissez le type !) de ne pas fournir d'entrée qui teste inutilement des valeurs impossibles.

Je ne souhaite pas désactiver la vérification de type, mais je n'ai aucun autre mécanisme pour consommer le code généré par le code en raison de cette erreur. Idéalement, je supprimerais cette erreur pour tous les fichiers générés par le code, mais conserverais toutes les autres vérifications de type.

Dans l'état actuel des choses, je n'ai pas de solution autre que de désactiver toutes les vérifications de type. À ce stade, je ne tire pas beaucoup de valeur de TypeScript par rapport à JavaScript simple

Êtes-vous sérieux? Cela reste un problème ouvert et non implémenté dans TS4 ? 🤦🏽

@ivnnv Vous pouvez utiliser // @ts-expect-error dans TS 3.9, voir ici

@ndraiman @ts-expect-error fonctionne pour des lignes individuelles mais pas pour des blocs , il est donc toujours nécessaire d'en placer plusieurs si l'on veut "ignorer un bloc"

Voici d'autres commentaires pour vous :

De quoi d'autres avez-vous besoin? Que doit faire la communauté pour obtenir cette fonctionnalité ?

Le meilleur cas d'utilisation pour cela est l'alternative à l'écriture any sur chaque type que l'on crée. Vous n'avez peut-être pas de sympathie pour l'esthétique (qui a sans aucun doute un impact sur l'humeur et la productivité), mais le simple fait d'avoir une alternative qui correspond aux attentes communes ne devrait pas être difficile à accepter.

Les gens ont des opinions différentes sur ce qui est acceptable et ce qui ne l'est pas.

Pour certaines personnes, cela prend trop de temps et limite l'état de flux dans lequel les gens peuvent se trouver lorsqu'ils font des choses banales comme le portage de code.
Je trouve ennuyeux et bizarre que je ne puisse pas avoir un bloc de code ignoré mais que je doive plutôt le salir avec des casts any , ce qui a souvent un effet néfaste sur la lisibilité (jusqu'à ce que les types appropriés soient là). Devoir continuellement écrire un nouveau commentaire ou se laisser distraire _juste parce que quelqu'un ne voit pas l'avantage d'ignorer des blocs de code_ n'est pas acceptable de mon point de vue.

EXEMPLE:

L'un porte un projet de JS vers TS, l'autre projet étant développé par un tiers.

La syntaxe et les règles suivies dans le projet porté peuvent être anciennes, par exemple es2015, ou obsolètes au profit d'une syntaxe plus claire et moins de code, etc.

Lors du portage de ce projet, une partie du code peut être extrêmement facile à porter vers TypeScript. Pourtant, on se heurte inévitablement, par exemple, à des booléens à moitié réfléchis et à des fonctions avec un comportement arbitraire qui nécessite plus de contexte ou doit être réfléchi pendant un certain temps pour créer ses types.

Ce serait tellement génial d'arrêter de vérifier une fonction ou un bloc de code dans un fichier tout en le corrigeant. Ignorer un bloc de code permettrait de se déplacer rapidement dans les domaines qu'ils connaissent et avec lesquels ils sont à l'aise et de conserver certaines parties pour plus tard.

Mon flux de travail lorsque je dois porter JavaScript sur TypeScript (et le code est, eh bien, en dessous de la moyenne):

1. Copiez le code du fichier .js vers le fichier .ts.
2. Voir si TS peut déduire des types par utilisation
3. Comprendre manuellement les types d'utilisation
4. Je réalise que les erreurs sont le fléau de mon existence
5. Essayez de commenter les erreurs, améliorant ainsi le nombre de lignes dans le fichier parfois x3 ESLlint + TS (plus c'est mieux ?)
6. Supprimez et ajoutez // @ts-check en haut tout en éditant soigneusement le reste des fichiers et ajoutez d'autres types.

Si nous pouvions ignorer les blocs :

1. Copier le code de .js vers .ts
2. Voir si TS peut déduire des types par utilisation
3. Comprendre manuellement les types d'utilisation
4. // @ts-ignore-enable ... // @ts-ignore-disable fonctions individuelles et blocs de code gênants
5. Décommentez les blocs au fur et à mesure que j'y accède et ajoutez des types

Décidez vous-même ce qui vous semble le plus raisonnable. C'est la même chose lors du portage de JS vers un projet avec beaucoup plus de règles ESLint, et vous devez refactoriser la plupart des choses.

J'aimerais que nous puissions faire comme c'est possible dans ESLint et utiliser /* eslint:disable */ ... /* eslint:enable */ dans TypeScript.

PS Je viens de réaliser en vérifiant ce commentaire que j'ai passé plus de 20 minutes à essayer d'obtenir une expérience que je (et beaucoup d'autres) recherche depuis 2017, juste pour commenter un problème ouvert de bientôt 3 ans.

@weswigham @RyanCavanaugh

Rappel :+1 :

Donnera le premier-né en échange de cela

@agusterodin Votre sacrifice attire l'attention des démons.....

D'accord, rien ne se passe en fait, sauf que je fais juste un simple PR :)

Cependant, personnellement, je suis fortement d'accord avec l'opinion de l'équipe TS -- cette fonction est diabolique, vous devriez toujours essayer d'éviter d'utiliser @ts-ignore , de ne pas utiliser @ts-ignore-enable (ou @ts-ignore-start , peu importe).
Mais parfois, vous savez, le proverbe dit drinking posion to satisfie thirst , je sais que c'est un mauvais choix, mais c'est juste dans le besoin.

edit : ajoutez une explication et des exemples.
Ce PR ajoute deux directives ts-ignore-enable et ts-ignore-disable .

1. si vous utilisez uniquement ts-ignore-enable, la partie restante est entièrement ignorée.

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

1. vous pouvez ajouter les mêmes directives plusieurs fois, mais elles ne fonctionnent qu'une seule fois.

// @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 pourrait être utilisé seul, rien ne se passerait.

2. @ts-expect-error ne fonctionnerait pas dans la région ignorée

// @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. pas d'étiquette de région, ce ne sont que des commentaires.

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

Dans un monde parfait, nous n'aurions pas besoin d'ignorer la sécurité des types, n'est-ce pas ? :sweat_smile:
J'en ai besoin pour copier un travail fantastique, par exemple des exemples et des démarreurs, même la réponse SO occasionnelle qui n'est pas tapée ou tapée comme je le voudrais. Surtout pour l'avoir dans mon code de type sécurisé qui suit mes paramètres. J'utilise juste des paramètres très stricts et je dois souvent réécrire une fonction ou une logique à cause de cela. Ce n'est pas parce que je veux continuer à ignorer ce bloc de code, cela n'aurait aucun sens.

Ignorer un bloc de code est une commodité qui me semble parfaitement raisonnable étant donné que je peux toujours @ts-ignore chaque ligne d'un bloc.

Je comprends les implications possibles que cela pourrait avoir pour les personnes qui utilisent I'll just ignore this because it's easier . Comme je le vois, quiconque pourrait utiliser la portée de bloc ignore à drink poison to satisfy their thirst boit déjà des gouttes de poison avec @ts-ignore .

Maintenant que vous pouvez faire @ts-nocheck dans les fichiers .ts , je suggère d'autoriser également @ts-check dans les fichiers .ts afin que nous puissions activer/désactiver le vérificateur de type :

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

Cela ne nécessite pas de définir ce qu'est un "bloc de code". Vous pouvez démarrer et arrêter la vérification de type de - à n'importe quelle ligne.

MISE À JOUR Je me suis trompé, voir https://github.com/microsoft/TypeScript/pull/40267#issuecomment -713840095 pour la correction.

Lorsque j'ai essayé de migrer une application en utilisant styled-components vers TypeScript, j'ai rencontré un problème où @ts-ignore ne peut pas être utilisé au-dessus des chaînes de modèle (pour une raison quelconque). Cela aurait pu être résolu avec un bloc d'ignorance.

Exemple d'erreur TS que j'essayais d'ignorer :

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

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

En guise de remarque supplémentaire : je ne peux en lancer aucun dans mon projet TS, je n'autorise aucun type. Quelle est la recommandation alors ?

@weswigham Que pensez-vous de l'état de flux et de la productivité dans le contexte de l'esthétique ? Il semble que vous n'ayez aucune sympathie pour les yeux qui saignent ; mais avez-vous des notions sur la productivité, le code de portage et les processus que j'ai décrits ? Ne voyez-vous toujours aucun avantage _du tout_, après avoir pris en compte mon commentaire, et dans le contexte d'être plus productif ? J'ai également décrit certaines situations réelles où il faudrait ignorer la portée du bloc. De plus, comment cette fonctionnalité ne se compare-t-elle pas à ESLint et à la fonctionnalité que nous y attendons ?

Il est scientifiquement prouvé que moins d'interruptions augmentent la productivité et améliorent l'efficacité ; l'ignorance de la portée du bloc permettrait moins d'interruptions lors du portage du code. L'équipe TS ne se rend-elle pas compte que "fondamentalement, nous pensons que vous ne devriez pas du tout utiliser de suppressions dans TypeScript". est une opinion basée sur la vie et la respiration de TypeScript, et que dans le monde réel, les gens ont besoin de porter du code mal écrit vers d'autres bases de code, avec plus de sécurité de type et d'autres règles de peluche ; dans ces situations, cela n'a pas de sens que vous puissiez ignorer un fichier ou une ligne, mais pas le bloc de code que vous venez d'importer.

Pour moi, il semble que vous visiez l'utopie tout en ignorant la réalité. @sandersn Vous n'avez abordé aucun de mes points et avez conservé l'ancienne réponse par rapport aux discussions plus récentes sur l'affaire. Vous déclarez également qu'à moins que l'équipe n'en décide autrement, il ne devrait pas être mis en œuvre, auquel cas : fermer le problème ?

L'équipe doit soit prendre une décision, soit implémenter une fonctionnalité clairement souhaitée.

Garder la question dans les limbes n'a aucun sens.

Je suis désolé que nous ne puissions pas vous donner la finalité dont vous avez besoin, mais la réalité est que "peut-être plus tard" est une réponse avec laquelle vous allez devoir apprendre à vivre. Une fonctionnalité donnée ne peut pas être précipitée dans le produit demain, et pour les fonctionnalités qui relèvent de nos paramètres de conception, il existe des milliers de suggestions actuellement ouvertes qui se disputent notre capacité à les ajouter au produit d'une manière ergonomique, utile, stable et avant-gardiste.

Nous priorisons les choses en fonction des commentaires actuels, de l'état des solutions et des solutions de contournement actuelles, de la prépondérance de ces scénarios, des outils et d'une centaine d'autres facteurs. Les choses qui ne sont pas prioritaires en ce moment peuvent devenir prioritaires plus tard. C'est la nature de "peut-être plus tard" et je pense que c'est une représentation précise de la position de cette suggestion. La décision ici, pour l'instant, est de continuer à surveiller les commentaires et à comprendre ce que les gens rencontrent qui pourrait nécessiter cette fonctionnalité comme étant une priorité plus élevée que toute autre fonctionnalité que nous pourrions ajouter ensuite, dont des centaines se disputent l'attention.

Le ton ici tend honnêtement vers l'hostilité et parle personnellement, être poussé vers un ultimatum n'est pas propice à une conversation constructive qui nous aide à comprendre où cela ajoute de la valeur qui dépasse sa complexité par rapport aux alternatives.

Je suis désolé d'avoir posé un ultimatum. J'ai été assez ennuyé de voir l'activité vers le PR, mais aucune sur la question. Je suis d'accord que mon commentaire précédent n'apporte aucune contribution constructive.

Je peux accepter que ce problème doive attendre. J'ai fourni quelques commentaires et j'ai demandé quels autres commentaires sont nécessaires pour se rapprocher de la résolution, mais je n'ai reçu aucune réponse. Il semble, aussi ennuyeux que cela puisse être, que mon commentaire plutôt non constructif était ce que je devais faire pour obtenir _quelque_ réponse de l'équipe.

Il semble toujours qu'aucune progression réelle vers un problème avec plus de 700 réactions positives, c'est-à-dire depuis plusieurs années, n'ait été faite. Je ne pense pas que cela devrait aller plus vite, mais il semble que l'équipe se désintéresse de l'exploration de cette fonctionnalité, car les membres ont des opinions personnelles à son encontre. Je comprends parfaitement toutes ces choses. Ce n'est pas ce dont je parle ici, cependant. Je veux engager une conversation, mais je suis ignoré.

J'aimerais savoir que mes commentaires sont pris en compte et, compte tenu de leur nature, traités. Ce n'est pas une grande perturbation dans l'ensemble des fonctionnalités, comme le montrent les relations publiques actives qui ont été lancées en peu de temps. Tout est prêt à l'emploi, les gens continuent de réagir positivement à la résolution de ce problème avec une fonctionnalité d'ignorance des blocs, et j'ai sonné en demandant ce que la communauté doit faire pour obtenir cette fonctionnalité. Je suis fortement en désaccord avec plusieurs des points soulevés par l'équipe et je me suis opposé à cela, un PR a été fait et un commentaire a été donné indiquant que "à moins que nous ne changions d'avis", rien ne changera.

C'est là que ma frustration fait surface. Vous souhaitez ignorer une fonctionnalité prête car aucun changement n'a été apporté à la décision d'un membre de l'équipe, ignorant complètement mes commentaires et ceux des autres.

Il semble qu'à moins qu'un membre de l'équipe n'en décide autrement _de son propre chef_, nous ne verrons aucun changement à ce sujet. Cela n'appelle pas plus de commentaires de la part de la communauté, n'est-ce pas ? C'est pourquoi j'ai mal fait l'ultimatum.

J'ai avancé plusieurs arguments contre les points de @weswigham , fourni quelques exemples et, honnêtement, j'attends toujours une réponse. La seule chose qui semblait aider était d'être visiblement contrarié et non constructif.

Comment allons-nous partir d'ici? Quels commentaires l'équipe aimerait-elle ? Cela semble être un problème personnel caché derrière "Nous priorisons les choses en fonction des commentaires actuels, de l'état des solutions et des solutions de contournement actuelles, de la prépondérance de ces scénarios, des outils et d'une centaine d'autres facteurs." puisque plusieurs personnes ont essayé de donner des commentaires sans aucune réponse de la part de l'équipe.

Je voudrais réitérer que je comprends que cela pourrait ne pas être une grande priorité si nous écartons les opinions des gens du sujet. Dans le même temps, la fonctionnalité est prête à être implémentée et des arguments ont été avancés. Ce qu'il faut maintenant, c'est que l'équipe prenne une décision/réponse (pas nécessairement mettre en œuvre quoi que ce soit) et la rende publique. Si ce n'est pas ce qui est requis, alors s'il vous plaît dites-moi ce que c'est, ou comment on pourrait aider à augmenter la priorité sur _any_ fonctionnalité ou problème pour TypeScript, mais surtout celui-ci.

Un autre cas d'utilisation pour multiline ( @ts-ignore-start+@ts-ignore-end ) ou inline (comme /* @ts-ignore */ ) @ts-ignore .
Environnement:

• "noUnusedParameters": true
• Règle ESLint require-jsdoc activée.
• Code similaire au suivant (exemple simplifié) :

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

Pour la situation décrite, TypeScript émet l'avertissement suivant : 'settings' is declared but its value is never read.(6133) .
Il est possible de supprimer l'avertissement en ajoutant @ts-ignore après la fin du commentaire de la documentation :

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

Mais après cela, ESLint se plaindra de Missing JSDoc comment .
Donc la solution est :

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

Ce qui est maladroit et laid.

@RyanCavanaugh @weswigham @sandersn

Un rappel mensuel indiquant que c'est quelque chose dont la communauté souhaite discuter plus avant avec l'équipe TypeScript. Il y a beaucoup de soutien et ce qui manque actuellement, c'est une réponse de l'équipe. Je comprends qu'il y a beaucoup de prépondérances et que la progression de TypeScript n'est pas une mince affaire. Les choses prennent du temps. Puisqu'il n'y a pas de réponse concernant la manière dont nous pouvons poursuivre cette suggestion et obtenir des mesures plus directes, je ferai régulièrement un rappel comme celui-ci. Je n'abandonne pas tant qu'une décision n'a pas été prise, et les commentaires semblent affecter (surtout quand je suis un !@# cependant).

Après ces années passées, même si j'étais initialement effrayé par l'absence de cette fonctionnalité, j'y ai personnellement repensé un peu... Quand il y a un énorme tas de @ts-ignore , vous pouvez déjà dire qu'il y a quelque chose qui ne va pas avec votre code et passez du temps à améliorer vos types. Nous sommes tous assez paresseux parfois et voulons de la vitesse dans l'ensemble, mais actuellement, il est souvent plus facile de comprendre quelques types appropriés plutôt que de copier-coller plusieurs @ts-ignore dans de gros tas de code. Si cet équilibre d'inconvénients est rompu, beaucoup d'entre nous abuseront commodément de @ts-ignore-enable, ce qui ne fera que diminuer la qualité globale de tous les petits projets open source ici et là.

Au fait, même si nous voyons qu'il y a beaucoup de réactions 👍 sur cette question, - cela pourrait être biaisé, car beaucoup plus de gens pourraient se sentir parfaitement bien sans cette fonctionnalité tout en étant silencieux, car ils ne sont pas là.

@JerryGreen En faisant référence à mes commentaires plus anciens, j'ai dit exactement la même chose. Avec l'ajout que les gens le font déjà avec la fonction Ignorer. Il n'y a aucune raison d'implémenter un peu de poison tout en prétendant qu'il ne devrait y en avoir _aucun_ .

Supprimez la fonctionnalité @ts-ignore ou rendez-la à part entière. Il existe de nombreux arguments pour ce faire, et les personnes qui écrivent du mauvais code continueront à utiliser @ts-ignore , ce qui est tout aussi mauvais qu'une fonctionnalité d'ignorance de bloc, c'est exactement la même chose - sauf que l'ignorance de bloc est moins perturbatrice visuellement.

La communauté a encore besoin d'une réponse de l'équipe TypeScript.

@JerryGreen En faisant référence à mes commentaires plus anciens, j'ai dit exactement la même chose. Avec l'ajout que les gens le font déjà avec la fonction Ignorer. Il n'y a aucune raison d'implémenter un peu de poison tout en prétendant qu'il ne devrait y en avoir _aucun_ .

Supprimez la fonctionnalité @ts-ignore ou rendez-la à part entière. Il existe de nombreux arguments pour ce faire, et les personnes qui écrivent du mauvais code continueront à utiliser @ts-ignore , ce qui est tout aussi mauvais qu'une fonctionnalité d'ignorance de bloc, c'est exactement la même chose - sauf que l'ignorance de bloc est moins perturbatrice visuellement.

La communauté a encore besoin d'une réponse de l'équipe TypeScript.

Certains scénarios spéciaux doivent encore utiliser @ TS ignore. Par exemple, l'import CDN ne dépend pas de node_The. Le fichier TS n'existe pas dans le scénario des modules

@L-Hknu Merci d'avoir clarifié. Les gens l'utilisent comme ils utilisent ignore avec ESLint de toute façon.

La fonctionnalité Ignorer n'est pas interdite dans des contextes autres que ceux où elle est nécessaire pour la fonctionnalité. Cela me dit que c'est correct de l'utiliser pour ignorer le code.

Je ne peux toujours pas expliquer pourquoi il ne devrait pas y avoir de bloc ignoré, car il est utilisé de la même manière la plupart du temps.

J'ai abandonné la conversion en types pour certains codes open source, car la progression de la conversion aurait été tellement plus confortable avec les blocs ignorés. Je n'en ai pas besoin, mais je pense que beaucoup de gens mettront un pied à l'intérieur de la porte avec la dactylographie ; en outre, de nombreuses personnes contribueraient très probablement aux conversions plus efficacement, en particulier compte tenu de la différence d'esthétique entre les commentaires de bloc et de chaque ligne.

Mon plus grand cas d'utilisation pour cette implémentation serait pour les packages tiers qui ne prennent pas en charge le tapuscrit, et je devrais ignorer certaines de ses utilisations.

@L-Hknu Merci d'avoir clarifié. Les gens l'utilisent comme ils utilisent ignore avec ESLint de toute façon.

La fonctionnalité Ignorer n'est pas interdite dans des contextes autres que ceux où elle est nécessaire pour la fonctionnalité. Cela me dit que c'est correct de l'utiliser pour ignorer le code.

Je ne peux toujours pas expliquer pourquoi il ne devrait pas y avoir de bloc ignoré, car il est utilisé de la même manière la plupart du temps.

J'ai abandonné la conversion en types pour certains codes open source, car la progression de la conversion aurait été tellement plus confortable avec les blocs ignorés. Je n'en ai pas besoin, mais je pense que beaucoup de gens mettront un pied à l'intérieur de la porte avec la dactylographie ; en outre, de nombreuses personnes contribueraient très probablement aux conversions plus efficacement, en particulier compte tenu de la différence d'esthétique entre les commentaires de bloc et de chaque ligne.

On dirait que c'est fait
#40267