この笑が必要です

この機能の現在の使用例は、空白を処理する単体テストです。 正当な理由でコードベースで「no-trailing-whitespace」ルールがオンになっていますが、ブロックレベルでそれを打ち負かすことができないということは、ES6テンプレート文字列を使用して末尾の空白とキャリッジリターンを簡単にテストできないことを意味します。

mathjsでカスタムバンドリング_ a.k.a partial import _を使用する私のユースケースの1つ

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

ファイル全体のエラーを無視したいのですが。 ES5にトランスパイルしたいES6JSコードをいくつか継承しましたが、現時点ではBabelを使用する必要があります。 ファイルの名前を.tsに変更し、TSでトランスパイルするだけでよいでしょう。

@ptallettは、 allowJsを使用して$ .jsファイルをコンパイルし、コンパイルに含めることができます。 デフォルトでは、ファイルの上部に// @ts-checkコメントがあるか、 checkJsをオンにしない限り、 .jsファイルでエラーは発生しません。

私はまだこの機能が大好きです、私はテストファイルに座っています、それは拡張子.tsを持っているので、どのパラメータがどこに行くのかをインポートして簡単に見ることができます、そしてそれをsrcファイルの横のディレクトリにコンパイルすることは私のユースケースにとって素晴らしいです。

一部のパラメーターを意図的に除外したり、関数に元のタイプとは異なるタイプを指定したりするため、ほとんどの行が赤になり、実行時にもチェックするため、エラーがスローされることが予想されます。

いたるところにたくさんの赤い線がないのは素敵でしょう。 :)

更新はありますか、または誰かがこれを行うための良い方法を見つけましたか？

TypeScriptでlodash 、特にlodash/fpを使用するのは非常に苦痛であり、最新バージョンのlodashと@types/lodashを使用しても、非常にわかりにくいエラーメッセージが表示される可能性があります。

次のブロックのエラーを無視する@ts-ignore-blockがあれば、_あなたが何をしているのかを知っている_このようなユースケースに最適です:-)

私は多数のグローバルスコープ変数を使用してレガシーコードを使用していますが、すべての行に@ ts-ignoreを書き込むのは面倒になりますが、これに関する更新はありますか？

また、このリクエストの更新を求めています。 ありがとう！

これは、私が行っていることにとっても非常に重要です（つまり、生成されたVueテンプレートレンダリング関数のタイプチェック。コードブロックの特定の検査を無効にする必要があります）。
この問題に加えて、＃19139は非常に重要です。特に、コードの大部分に適用する場合は、特定の検査のみを無効にする必要があるためです。

ホールファイルを抑制することで、これをvscodeなどのエディターに追加してワークスペース設定などに保存できます。

これも必要です。 graphql-code-generatorを使用してGraphQLスキーマの型を含むtsファイル全体を自動生成していますが、noUnusedLocalsをトリガーする無関係なインポートがあります。

/ * tslint：disable * /

コード

/ * tslint：enable * /

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

と組み合わせることができます： https ：//github.com/Microsoft/TypeScript/issues/19139

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

@marianturchynこれはtslintではありません。

物事を移動してリファクタリングしているときに、CLIオプションをいじらずに、ファイル全体を一時的に無視したい（つまり、コンパイルしない）場合があります。

最も速い/最も簡単なのは、ファイルの先頭にあるフラグです。

// @ts-ignore-file

@ lonix1ユースケースは次の対象です。

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

// @ts-ignore-endの部分を使用する必要はありません。 多くのリントツールはそのように機能します。

@mgolこのスレッドを脱線させたくありません...しかし、私はあなたの提案を試しました-ありがとう！ -そしてそれは私にとってはうまくいきませんでした。 ファイルの上部に行をまとめ、一方を上部に、もう一方を下部に試しました。
他の誰かがそれを機能させることができますか？

@ lonix1 @Blanenの提案もあなたのために働くことを意味しました、 // @ts-ignore-start + // @ts-ignore-endと// @ts-ignore-fileの両方を実装するためにTypeScriptを必要とせず、 // @ts-ignore-startを実装します// @ts-ignore-endで十分です。 これは実装されていないため、この問題は未解決のままです。

@DanielRosenwasserこれは、ビルド中にtsファイルが別のフォルダーに保存された場合にのみ機能します。 プロジェクトがtsファイルの隣にjsファイルを配置するように設定されている場合。 また、jsファイルは「コンパイル」されますか？たとえば、es5に変換されますか？ レガシーコードを転送するとき、これは本当に役に立ちます。

この機能が必要です。

使用事例：

TypeORMは、null許容の場合とそうでない場合のある列を持つDBエンティティクラスを作成することを想定しています。 多くの列（したがって）はnull許容ではありません。したがって、クラス定義を除いて、プロパティが特定の定義された型の無条件であるかのように扱う必要があります。 ただし、Typescriptでは、すべての列を強く型付けされているものとして定義する必要があります。 したがって、次のような非常に多くのエンティティが作成されます。

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

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

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

すべての列が必須であり、（したがって）必ず値が含まれますが、TypeORMの動作方法により、すべてのプロパティは初期化子がないように定義する必要があります。 クラス全体（したがって/またはファイル）について、この特定のORMから派生した/特定の問題を抑制できると非常に便利です。

@haggholm public metadata!: IEncryptedJSONContainerよりもts-ignoreを好む理由はありますか？

@RyanCavanaugh無知！ ドキュメントでその機能を見逃していました。 ごめん; 無視して下さい。

やりたい

// @ ts-ignore-start
-特定のファイルのnullチェックを実行します

これは、typescriptを使用してプライベートフィールドとメソッドをユニットテストするものです。 コードを無視するための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は、複数行と単一行のインポートを異なる方法で処理します。

型付けがない、またはNoImplicitAnyなしで記述されたnpmモジュールはまだたくさんあります。
その結果、「暗黙的」エラーが発生し、インポートされます。

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

だから私は@ ts-ignoreを使うことができます：

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

しかし、自動インポートとPrettierのようなフォーマッターを使用すると、これが発生します。
（Prettierによるフォーマット）

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

私はそれを修正することができます：

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

また

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

しかし、その後、単一行のインポートでは次のようになります。

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

モジュールからインポートされる要素の数に応じて、自動インポートとフォーマットが単一行インポートと複数行インポートの間で変わるため、このように記述する必要があります。
インポートコードを手動で変更すると、自動インポートの目的が実際に無効になります。

すべてのインポートでts-ignore-startとts-ignore-endを記述する必要がないのは良いことです。
したがって、 // @ ts-ignore （次の行だけでなく）のインポートは、ts-ignoreが処理する必要があるものだと私は考えています。 （または、@ ts-ignore-block / @ ts-ignore-importのような他の無視）

ファイル全体で特定のエラーを抑制する必要があります。

// @ts-ignore-all TS1206

/*
... rest of the file
*/

このスレッドで言及されているユースケースを処理するために// @ts-ignore-startと// @ts-ignore-endのコメントを提案した上記の人々と一致しています。

これは、現在の// @ts-ignoreディレクティブと非常によく似ており、 // @ts-ignore-startディレクティブだけが先頭にあるファイル内のすべてのエラーを無視できるため便利です。

上記の提案の多くには、前向きなユースケースがあります。 私が提案する：

現在の動作としての@ts-ignore
@ts-ignore TSxxx [TSxxx ...]は特定のエラーを抑制します
@ts-ignore-start無視する開始ブロック
@ts-ignore-start TSxxx [TSxxx ...]はブロックの特定のエラーを抑制します
@ts-ignore-endエンドブロック
@ts-ignore-allファイルの残りのエラーを抑制します
@ts-ignore-all TSxxx [TSxxx ...]は、ファイルの残りの部分の特定のエラーを抑制します

「特定のエラー」には、tsconfigにあるものと同様の名前付きグループ、またはTSxxxエラーのユーザー定義グループが含まれる可能性があります。

インポートされたモジュールをネストするignoreブロックの値についてはよくわかりません。 私の好みは、インポートされたモジュールファイル内のブロックを明示的にts-ignoreします。 しかし、サードパーティのライブラリをインポートする場合、これには理由があるかもしれないので、私はここでフェンスにいます。

.tsignoreファイルが欲しかった

.npmignore ＆ .gitignoreのように

無視ブロックがあるはずです。 puppeteerフレームワークで行き詰まりました。 puppeteerでは、ページ上で任意のスクリプトブロックを実行できる「evaluate」メソッドを使用しています。 この任意のスクリプトブロックには、ページで使用できる関数への参照が含まれている可能性があります。つまり、関数参照は実行時に使用できます。

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

これは、レガシーコードのチャンクを操作するときに非常に便利であり、TypeScriptに切り替えるのに苦労することはありません。

だいたい

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

私は以前にこの提案をしましたが、構文を変更したいと思います。
開始-停止または開始-終了のいずれかにします
startとend （動詞として）は反意語ではないので、typescriptに入ると、これは永遠に気になります。

それは私にとってクールです

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

非常に必要な機能。

なぜこれがまだ不可能なのですか？ :-(

私もブロック無視する必要があります

+1

+1

これに関する更新はありますか？

🙏🏻

そして、私たちが通常エスリントで行うのと同じようにそれを行う場合はどうなりますか？

/* @ts-disable */

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

/* @ts-enable */

上記のように：未使用の変数が発生する可能性のあるTSコード（Swaggerを使用など）を生成するとすぐに、この機能が必要になります。

+1

//@ts-ignore-fileがないと、TSに移行することはできません

だから、誰も気づかずに真実ではない

@RyanCavanaughコミュニティは明らかにこれを必要としていますが、これが対処されていない理由はありますか？ ありがとう！

Typescriptが泣いてレンダリングをブロックしなければ、ソリューションが実行可能かどうかを確認するためのソリューションを試してみることができないため、現在これに苦労しています。

現在、この機能が必要です。

関心のないいくつかの関数のノードタイプを持つパブリックライブラリをインポートしています。したがって、 skipLibCheckを使用して無視するのではなく、// @ ts-ignoreを単一のインポートに使用すると便利です。すべてのライブラリ。

最初は// @ ts-ignore-fileのアイデアが好きでしたが、一貫性を保つために// @ ts-ignoreの方がおそらくうまくいくでしょう。

だから....私はtypescriptファイルで//@ts-nocheckをサポートして＃33383を開きました。 さて、私たちは_TypeScript_コンパイラチームなので、実際にはわかりません（起こりそうな問題を修正していません、whaaaat !!？！？）-typescriptの//@ts-ignoreでさえ、腕がねじれたために問題になりました少しなので、私たちは....躊躇しています...さらに抑制メカニズムを追加することを躊躇しています。 ですから、もしあなたが本当にそのような幅広い抑制メカニズムが必要だと感じたら、あそこに行って👍

@weswigham 、これはおそらく最も重要な機能ではありませんが。 開発中に便利かもしれません。 数行のコードに一時的にコメントするのと同じように、他の場所で問題を開発して切り分けようとするときに役立つ場合があります。 ただし、この方法で実行時のバグを実際に引き起こす方法が見つからないように、警告を受け取りたいと思います。 おそらく、開発のみでこの機能を有効にしますが、ビルド時にエラーをスローします。

この問題にはまだ「フィードバックを待っています」というラベルが付いているので、次のようになります。

新しいアーキテクチャの方向性をすばやくプロトタイピングするときは、新しいアーキテクチャが機能することを確認するために、TypeScriptを使用してプロトタイプを作成したいと思います。 ただし、実験中は、単体テストファイルのタイプエラーを一時的に無視したいと思います。

各ファイルの先頭にある種の@ts-ignore-コメントを追加するのは簡単です。

2番目の@ kumar303の必要性：ユニットテストでは、その特定のブロック/ファイルのチェックをオフにすることが有益です。これらのケースをカバーするのはアサーションになるからです。

@weswighamコンパイラフラグの後ろに置くことができます。

コンパイラフラグの後ろに置くことができます。

必要ありません-3.7ベータ版です。

再： https ：//github.com/microsoft/TypeScript/pull/33383： @weswigham素晴らしい、ありがとう！ ここでの強力なユースケースは、ファイルの型チェックを一時的に無視することです。そのため、 @ts-nocheckを削除し忘れた場合に失敗するlintルールを出荷することもお勧めします。

gatsbyに問題があり、静的graphQLクエリは.jsxファイルでは機能しますが、 .tsxファイルでは機能しません。 この提案は、より受け入れやすい回避策になると思います。 （ここで発行https://github.com/AdamLeBlanc/gatsby-plugin-ts-loader/issues/5）

おい！
提案されたソリューションは実装されていますか？

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

非常に有益だと思います。 私はそれに取り組んでもかまいません。

3.7でファイル全体のすべてのエラーを抑制するために、 //@ts-nocheckのサポートを追加しました。 行レベルとファイルレベルの抑制は、大騒ぎせずに_ほとんどの_ニーズを網羅できると思います。 チェックされていないファイル内に十分に大きなブロックがあり、チェックを外す必要がある場合は、ファイル全体のチェックを無効にするか、それが不快な場合は、チェックされていないチャンクを独自のファイルに抽出して、そのファイルのチェックを無効にするか、失敗した場合は、実際の問題で各行を抑制しますか？ ts-ignoreは単一の問題を無視することになっていますが、 ts-nocheckは単一のファイルを無視することになっています-範囲ベースの抑制は実際には特定のユニットにマップされないため、どういうわけか悪いようです（抑制している単一の問題または根本原因にマップできないため）。 少なくともエラーコード固有の抑制がなければ、私は範囲ベースの抑制に特に慣れていません。

少なくとも、ファイルの先頭に1つの抑制（ //@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 ）を付けることをお勧めします。 「複数の連続した書き込み抑制は私の目を出血させます」、基本的に、TypeScriptで抑制を使用するべきではないと私たちは信じているので、私は_zero_同情しています。 それが型の問題である場合は、それをキャストすることができます（そのため、 any 、キャスト、および短縮モジュール宣言が存在します）。 構文の問題である場合、すべてがひどく、とにかく壊れてしまうので、抑制は何もしません（抑制は解析エラーに影響しません）。

//@ts-nocheckをありがとう、しかしこれはコードブロックのチェックを無効にする問題を解決しません：

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

// @ts-nocheck

興味深いユースケースがあります。

TypescriptでORMを構築または所有し、acornを使用してステートメントをDDLにコンパイルします。

whereクエリを実行するには、スコープ変数を渡す必要があります。

.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は私のtsangularプロジェクトでは機能しませんが、 //@ts-ignoreは機能します。 マイクロソフトのこの問題は2017年に始まりました。2017年！ おお...

今から3年、解決策はありません。 JavaScript開発者がtypescriptにジャンプしたくないのは当然のことです

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

と組み合わせることができます：＃19139

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

@marianturchynこれはtslintではありません。

これを実装する計画はありますか？

// @ts-nocheck
現在のところ唯一のオプションです:(

ここで検討するために追加する別のユースケース...

私は、いくつかの基本的な制御フローと条件を可能にする社内のマークアップ言語から一連のTypeScriptコードを生成するコードです。 コード生成の動作を制御しますが、コードジェネレーター（エンドユーザー次第）に渡される入力は制御しません。

その結果、生成されたコードには到達不能コードが含まれている可能性があります。または、列挙型定数に対して値をテストするネストされたコードが存在する可能性があるため、TS2367の場合、そのブロック内に別の列挙型定数に対するその変数の別のチェックが含まれます。 例えば：

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

手書きのコードを使用すると、このパターンを簡単に修正して回避できます。 ただし、コード生成では、不可能な値を不必要にテストする入力を提供しないのは、私のユーザー（開発者、タイプを知っています！）次第です。

タイプチェックを完全に無効にしたくはありませんが、このエラーのためにコード生成コードを消費する他のメカニズムはありません。 理想的には、すべてのコード生成ファイルに対してこの1つのエラーを抑制しますが、他のすべての型チェックは保持します。

現状では、すべての型チェックをオフにする以外に解決策はありません。 その時点で、TypeScriptとプレーンJavaScriptの価値はあまり得られていません。

真剣ですか？ これはまだ未解決の問題であり、TS4には実装されていませんか？ 🤦🏽

@ivnnv TS 3.9では// @ts-expect-errorを使用できます。こちらをご覧ください

@ndraiman @ts-expect-errorは個々の行に対して機能しますが、ブロックに対しては機能しません。したがって、「ブロックを無視」したい場合は、それらの多くを配置する必要があります。

フィードバックは次のとおりです。

他に何か要りますか？ この機能を利用するには、コミュニティは何をする必要がありますか？

これの最良の使用例は、作成しているすべてのタイプにanyを書き込む代わりの方法です。 あなたは美学に共感しないかもしれませんが（それは間違いなく気分と生産性に影響を与えます）、一般的な期待に一致する代替案を持っているだけで受け入れるのは難しいことではありません。

何が受け入れられ、何が受け入れられないかについて、人々は異なる見解を持っています。

一部の人々にとって、それは時間がかかりすぎて、コードの移植のようなありふれたことをしている間、人々が入ることができるフロー状態を制限します。
コードのブロックを無視することはできず、代わりにanyのキャストを散らかす必要があるのは面倒で奇妙だと思います。これは、読みやすさに悪影響を与えることがよくあります（適切なタイプが存在するまで）。 継続的に新しいコメントを書いたり、気を散らすものにふける必要があるのは、誰かがコードのブロックを無視することの利点を理解していないという理由だけで、私の見解では問題ありません。

例：

1つはJSからTSにプロジェクトを移植し、もう1つはサードパーティによって開発されています。

移植されたプロジェクトで従う構文とルールは、古いもの（es2015など）にすることも、より明確な構文と少ないコードを優先して非推奨にすることもできます。

このプロジェクトを移植する場合、一部のコードはTypeScriptへの移植が非常に簡単な場合があります。 それでも、必然的に、たとえば、ブール値や、より多くのコンテキストを必要とするか、その型を作成するためにしばらくの間考えなければならない任意の動作を伴う関数について、半ば考えられたものに遭遇します。

それを修正している間、ファイル内の関数またはコードのブロックをチェックするのをやめるのはとても素晴らしいでしょう。 コードブロックを無視すると、自分が知っていて快適な領域にすばやく移動し、後で使用できるように特定の部分を保存できるようになります。

JavaScriptをTypeScriptに移植する必要があるときの私のワークフロー（そしてコードはまあ、サブパーです）：

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で可能なように、TypeScriptで/* eslint:disable */ ... /* eslint:enable */を使用できたらいいのにと思います。

PSこのコメントをチェックしたとき、私（および他の多くの人）が2017年以来求めていた経験を得るために20分以上費やしたことに気づきました。まもなく3年前の未解決の問題についてコメントするだけです。

@weswigham @RyanCavanaugh

リマインダー：+1：

これと引き換えに長子をあげます

@agusterodinあなたの犠牲は悪の注意を引き付けます.....

さて、私が単純なPRを与えることを除いて、実際には何も起こりません:)

ただし、個人的には、TSチームの意見に強く同意します。この関数は悪です。$ @ts-ignore-enable （または@ts-ignore-start ）を使用するのではなく、常に@ts-ignoreの使用を避けるようにしてください。 、 なんでもいい）。
しかし、時々、あなたが知っている、ことわざはdrinking posion to satisfie thirstと言います、私はそれが悪い選択であることを知っています、しかしそれはただ必要とされています。

編集：説明と例を追加します。
このPRは、2つのディレクティブts-ignore-enableとts-ignore-disableを追加します。

1. ts-ignore-enableのみを使用する場合、残りの部分はすべて無視されます。

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

1. 同じディレクティブを何度も追加できますが、機能するのは1回だけです。

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

1. // @ts-ignore-disableは単独で使用でき、何も起こりません。

2. @ts-expect-errorは無視された領域では機能しません

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

1. 地域ラベルはありません。コメントです。

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

完璧な世界では、型安全性を無視する必要はありませんよね？ ：sweat_smile：
例やスターターなどの素晴らしい作品をコピーするときに必要です。たまに入力されない、または入力されていないSOの回答も必要です。 ほとんどの場合、私の設定に従うタイプセーフコードにそれを含めるためです。 私は非常に厳密な設定を使用しているだけで、そのために関数やロジックを書き直さなければならないことがよくあります。 それは、私がそのコードのブロックを無視し続けたいからではなく、それは意味がありません。

コードのブロックを無視することは便利です。ブロック内のすべての行を@ts-ignoreできるという事実を考えると、私には完全に合理的と思われます。

これがI'll just ignore this because it's easierに行く人々に与える可能性のある影響を理解しています。 私が見ているように、ブロックスコープを使用できる人は誰でもdrink poison to satisfy their thirstを無視して、すでに@ts-ignoreで毒を一滴飲んでいます。

.tsファイルで@ts-nocheckを実行できるようになったので、 .tsファイルでも@ts-checkを許可して、タイプチェッカーのオン/オフを切り替えることをお勧めします。

import fs from 'fs'

fs.readFileSync(32423) // type checking

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

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

これは、「コードブロック」が何であるかを定義する必要はありません。 -から任意の行までタイプチェックを開始および停止できます。

更新私は間違っていました。修正についてはhttps://github.com/microsoft/TypeScript/pull/40267#issuecomment-713840095を参照してください。

styled-componentsを使用してアプリをTypeScriptに移行しようとすると、（何らかの理由で）テンプレート文字列の上で@ts-ignoreを使用できないという問題が発生しました。 無視ブロックで解決できたはずです。

無視しようとしたTSエラーの例：

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

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

追記：TSプロジェクトではキャストできません。タイプは許可していません。 それでは、推奨事項は何ですか？

@weswigham美学との関連で、フロー状態と生産性についてどう思いますか？ 目の出血には同情していないようです。 しかし、生産性、コードの移植、および私が説明したプロセスについて何か考えはありますか？ 私のコメントを検討した後、そしてより生産的であるという文脈において、あなたはまだ何の利益も見ていませんか？ また、ブロックスコープを無視する必要がある実際の状況についても説明しました。 さらに、この機能は、ESLintやそこで期待される機能とどのように比較されませんか？

中断が少ないと生産性が向上し、効率が向上することが科学的に証明されています。 ブロックスコープを無視すると、コードを移植する際の中断が少なくなります。 TSチームは、「基本的に、TypeScriptで抑制を使用するべきではないと考えています」と認識していませんか。 生きて呼吸しているTypeScriptに基づく意見であり、現実の世界では、タイプの安全性や他のリンティングルールを強化して、記述が不十分なコードを他のコードベースに移植する必要があります。 このような状況では、ファイルや行を無視できるのは意味がありませんが、インポートしたばかりのコードのブロックは無視できません。

私には、現実を無視してユートピアに向かっているように思えます。 @sandersnあなたは私の論点のいずれにも対処せず、この事件の新しい議論について古い回答を保持しました。 また、チームが別の方法で決定しない限り、実装すべきではないと述べています。その場合、問題を解決しますか？

チームは、決定を下すか、明らかに必要な機能を実装する必要があります。

問題を浮き彫りにしておくことは意味がありません。

申し訳ありませんが、必要なファイナリティを提供することはできませんが、現実には、「多分後で」が、一緒に暮らすことを学ばなければならない答えです。 特定の機能を明日製品に投入することはできません。設計パラメータに該当する機能については、人間工学に基づいた方法で製品に追加する能力をめぐって、現在開かれている何千もの提案があります。便利で、安定していて、前向きです。

現在のフィードバック、現在のソリューションと回避策の状態、それらのシナリオの優位性、ツール、およびその他の100の要因に基づいて優先順位を付けます。 現在優先度が高くないものは、後で優先度が高くなる可能性があります。 それが「たぶん後で」の性質であり、それはこの提案がどこにあるかを正確に表したものだと思います。 ここでの決定は、今のところ、フィードバックを監視し続け、人々が何に遭遇しているのかを理解することです。この機能は、次に追加する可能性のある他の機能よりも優先度が高いため、何百もの注目を集めています。

ここでの口調は正直に敵対的で個人的に話す傾向にあり、最後通告に向かって押し込まれたことは、これが代替案と比較してその複雑さを上回る付加価値をどこにもたらしているかを理解するのに役立つ建設的な会話を助長しません。

最後通告を設定して申し訳ありません。 私はPRに向けた活動を見て非常にイライラしましたが、この問題については何もありませんでした。 私の以前のコメントが建設的な方法で貢献していないことに同意します。

この問題は待つ必要があるかもしれないことを私は受け入れることができます。 いくつかのフィードバックを提供し、解決に近づくために他にどのようなフィードバックが必要かを尋ねましたが、応答がありませんでした。 どんなに厄介なことかもしれませんが、私のかなり非建設的なコメントは、チームから_何らかの_応答を得るために私がしなければならないことだったようです。

数年前の700以上の肯定的な反応を伴う問題への実際の進展はまだなされていないようです。 もっと速くなるとは思いませんが、メンバーが個人的な意見を持っているので、チームはこの機能を探求することに無関心であるようです。 私はこれらすべてを完全に理解しています。 しかし、それは私がここで取り組んでいることではありません。 会話をしたいのですが、無視されています。

私のフィードバックが考慮され、その性質を考慮して応答されたことを知りたいと思います。 これは、機能セットの大きな混乱ではありません。これは、短時間で起動したアクティブなPRによって示されます。 すべての準備が整い、ブロック無視機能を使用してこの問題の解決に積極的に反応し続けています。私は、この機能を取得するためにコミュニティが何をしなければならないかを尋ねました。 私はチームからのいくつかの論点に強く反対し、それに反対し、PRが行われ、 「私たちが考えを変えない限り」何も変わらないというコメントが与えられました。

それが私の欲求不満が表面化するところです。 チームメンバーからの決定に向けて変更が加えられておらず、自分自身や他の人のフィードバックを完全に無視しているため、準備完了機能を無視する必要があります。

チームの誰かが別の方法で_彼らの合意に基づいて_決定しない限り、この問題に関する変更は見られないようです。 それはコミュニティからのさらなるフィードバックを必要としませんね？ だから私は間違って最後通告を作ったのです。

私は@weswighamの論点に対していくつかの議論をし、いくつかの例を提供しましたが、正直なところ、それに対する何らかの応答をまだ待っています。 助けになったと思われる唯一のことは、目に見えて動揺し、非建設的であったことでした。

ここからどのように移動しますか？ チームはどのようなフィードバックを望みますか？ 「現在のフィードバック、現在の解決策と回避策の状態、それらのシナリオの優位性、ツール、およびその他の100の要因に基づいて優先順位を付ける」の背後に隠された個人的な問題のようです。 何人かの人々がチームからの応答なしでフィードバックを提供しようとしたので。

繰り返しになりますが、私たちが人々の意見を主題から遠ざければ、これは優先度が高くないかもしれないことを理解しています。 同時に、機能を実装する準備が整い、議論がなされました。 今必要なのは、チームが決定/応答（必ずしも何も実装する必要はありません）を行い、それを公開することです。 それが必要なものではない場合は、それが何であるか、またはTypeScript、特にこれに関する_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...
}

説明されている状況では、TypeScriptは次の警告を発します： 'settings' is declared but its value is never read.(6133) 。
ドキュメントコメントの最後に@ts-ignoreを追加することで、警告を抑制することができます。

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

しかしその後、ESLintはMissing JSDoc commentについて文句を言います。
したがって、解決策は次のとおりです。

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

これは厄介で醜いです。

@RyanCavanaugh @weswigham @sandersn

これは、コミュニティがTypeScriptチームとさらに話し合いたいことであるという毎月のリマインダーです。 多くのサポートがあり、現在欠けているのはチームからの応答です。 圧倒的なことがたくさんあり、TypeScriptを進歩させるのは簡単なことではありません。 物事には時間がかかります。 この提案をさらに進め、より直接的な行動を取る方法については回答がないため、定期的にこのようなリマインダーを作成します。 私は決定が下されるまで諦めません、そしてコメントは影響を与えるようです（しかし主に！@＃であるとき）。

これらの年月が経過した後、私はもともとこの機能がないことにびっくりしましたが、私は個人的にそれを少し再考しました... @ts-ignoreの膨大な束があるとき、あなたはすでに何かが間違っていると言うかもしれませんあなたのコードで、そしてあなたのタイプを改善することに少し時間を費やしてください。 私たちは皆、時々かなり怠惰で、全体的にスピードを求めていますが、現在、複数の@ts-ignoreを大きなコードの束にコピーして貼り付けるよりも、いくつかの適切なタイプを見つける方が簡単な場合がよくあります。 この不便さのバランスが崩れると、私たちの多くは@ ts-ignore-enableを悪用することになり、あちこちにあるすべての小さなオープンソースプロジェクトの全体的な品質が低下するだけかもしれません。

ところで、この問題には多くの👍反応があることがわかりますが、バイアスがかかっている可能性があります。なぜなら、ここにいないため、沈黙している間、この機能がなくても完全に元気になる人がはるかに多いからです。

@JerryGreen私の古いコメントを参照して、私はまったく同じことを言いました。 加えて、人々はすでに無視機能でこれを行っています。 _none_があるべきだと主張している間、少しの毒を実装する理由はありません。

@ts-ignore機能を削除するか、本格的にします。 これを行うには多くの議論があり、悪いコードを書いている人は@ts-ignoreを使い続けます。これは、ブロック無視機能と同じくらい悪いですが、ブロック無視が視覚的な混乱を少なくすることを除いて、まったく同じです。

コミュニティはまだTypeScriptチームからの応答を必要としています。

@JerryGreen私の古いコメントを参照して、私はまったく同じことを言いました。 加えて、人々はすでに無視機能でこれを行っています。 _none_があるべきだと主張している間、少しの毒を実装する理由はありません。

@ts-ignore機能を削除するか、本格的にします。 これを行うには多くの議論があり、悪いコードを書いている人は@ts-ignoreを使い続けます。これは、ブロック無視機能と同じくらい悪いですが、ブロック無視が視覚的な混乱を少なくすることを除いて、まったく同じです。

コミュニティはまだTypeScriptチームからの応答を必要としています。

一部の特別なシナリオでは、@ TSignoreを使用する必要があります。 たとえば、CDNインポートはnode_Theに依存しません。 TSファイルがモジュールシナリオに存在しません

@ L-Hknu明確にしてくれてありがとう。 とにかくESLintで無視を使用するので、人々はそれを使用します。

無視機能は、機能に必要な場合を除いて、コンテキストで禁止されていません。 これは、コードを無視するために使用しても問題ないことを示しています。

ほとんどの場合同じように使用されるため、ブロック無視がない理由はまだわかりません。

変換の進行はブロック無視の方がはるかに快適だったので、私はいくつかのオープンソースコードの型への変換をやめました。 私はそれを必要としませんが、多くの人がタイピングでドアの中に足を踏み入れると思います。 さらに、特にブロックコメントとすべての行コメントの間で美学がどれほど異なるかを考えると、多くの人がより効率的に変換に貢献する可能性があります。

この実装の私の最大のユースケースは、typescriptをサポートしていないサードパーティのパッケージであり、その使用法のいくつかを無視する必要があります。

@ L-Hknu明確にしてくれてありがとう。 とにかくESLintで無視を使用するので、人々はそれを使用します。

無視機能は、機能に必要な場合を除いて、コンテキストで禁止されていません。 これは、コードを無視するために使用しても問題ないことを示しています。

ほとんどの場合同じように使用されるため、ブロック無視がない理由はまだわかりません。

変換の進行はブロック無視の方がはるかに快適だったので、私はいくつかのオープンソースコードの型への変換をやめました。 私はそれを必要としませんが、多くの人がタイピングでドアの中に足を踏み入れると思います。 さらに、特にブロックコメントとすべての行コメントの間で美学がどれほど異なるかを考えると、多くの人がより効率的に変換に貢献する可能性があります。

完了したようです
＃40267