Vscode: 機能リクエスト：開いたファイルだけでなく、すべてのファイルのプロジェクト内のすべてのエラーと警告を表示します

@waderyanこれは、TSチームと話し合ったビルダー作業の機能リクエストです。

参考までに、この問題へのリンクを示します-https：//github.com/Microsoft/TypeScript/issues/11229

さて、私は"problemMatcher": "$tsc-watch" （https://code.visualstudio.com/Docs/editor/tasks#_processing-task-output-with-problem-matchersを参照）とすべてのエラーで監視ビルドタスクを使用します警告は、問題ビューに正しく表示されます。 開いているファイルの変更は言語サーバーによってすぐに通知されるため、これは非常に優れたワークフローですが、保存するとインクリメンタルコンパイル（ tsc --watch ）がトリガーされ、それでもしばらく時間がかかりますが、保存する/保存しないことでそのレイテンシーを制御できますまだ。

これに関するETAはありますか？ その機能には多くの問題があり、何かを見逃したかどうかはわかりません：smile：

@ maxime1992フォローアップに感謝します。 これは私たちのレーダーです。 まだ確固たるスケジュールはありません。

私が気付いていなかったのは、VSCodeが持っているTasksインフラストラクチャでこれを行うことが可能であるということでした。 あなたがしなければならないのはあなたのtasks.jsonにこれを入れることです：

{
  "version": "0.1.0",
  "command": "tsc",
  "isShellCommand": true,
  "args": ["-w", "-p", "."],
  "showOutput": "silent",
  "isBackground": true,
  "problemMatcher": "$tsc-watch"
}

次に、それを実行するだけで、プロジェクト全体のすべてのエラーが問題ビューに表示されます。

これがもっと目立つように表示されないのはなぜか少し戸惑います。 とても便利でかっこいいです。

@johnfnすばらしい解決策、どうもありがとう。 タスクの唯一の目的がエラーを表示することである場合は、「-noEmit」引数を追加することもできます

{
  "version": "0.1.0",
  "command": "tsc",
  "isShellCommand": true,
  "args": ["-w", "-p", ".", "--noEmit"],
  "showOutput": "silent",
  "isBackground": true,
  "problemMatcher": "$tsc-watch"
}

@kevinjreece iTermのセマンティック履歴機能（https://www.iterm2.com/documentation-one-page.html）を使用して、「端末とVSCodeの間の楽しいダンス」を防ぐことができます。 cmdがファイル名+行番号をクリックすると、vscodeで対応する行が自動的に開きます。

エラーのあるファイルを開くことができるかどうか/キーボードショートカットを使用して問題パネルで開くことができるかどうか誰かが知っていますか？ タスクを実行した後でも、マウスとキーボードを切り替え続けるのは本当に苦痛です。

Ctrl+Shift+M （またはCmd+Shift+M ）で問題パネルを開くことができます。これは[問題の表示]としてキーボードショートカットの下にあります-それはどういう意味ですか？

いいえ、開いているかどうかに関係なく、エラーのある次のファイルに移動するためのショートカットが必要です。

私はそれを行うための拡張機能を作成することを検討していましたが、APIはしっかりとロックされており、コマンドは私が見ることができる方法でMarkerServiceにアクセスできません（問題を追跡します）。

ああなるほど。 それは非常に便利かもしれません。 一般的に、vscodeのProblems領域には、改善する機会がたくさんあるようです。

この問題が発生している人はhttps://github.com/Microsoft/vscode/issues/34412？
後続のビルド間でまったく同じエラーが発生した場合、それは無視されます

デバッグタスクへのtscのトリックは、常に可能であるとは限りません。たとえば、カスタムWebpackローダーを使用して.vueファイルを処理するVueプロジェクトでは（ tscはVueファイルをすぐに解析できません） ）。

ただし、プロジェクトを監視してVS Codeターミナルにコンパイルすることで、すべてのエラーを発生させる方法を見つけることができます。

たとえば、私はこのnpmスクリプトを実行しました。
"live-check": "webpack --config ./build/webpack.dev.conf.js -w --display none",

そして、「npm run live-check」を介してVSターミナルに起動すると、すべてのエラーがリアルタイムで発生します。

@johnfnのソリューションを
[出力]タブでタスクが実行されているのがわかりますが、エラーは表示されません

tasks.json：

{
    "version": "0.1.0",
    "command": "tsc",
    "isShellCommand": true,
    "args": ["-w", "-p", ".", "--noEmit"],
    "showOutput": "silent",
    "isBackground": true,
    "problemMatcher": "$tsc-watch"
  }

tsconfig.json

{
  "compilerOptions": {
    /* Basic Options */
    "target": "es2015",                       /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', or 'ESNEXT'. */
    "module": "es2015",                       /* Specify module code generation: 'commonjs', 'amd', 'system', 'umd' or 'es2015'. */
    // "lib": [],                             /* Specify library files to be included in the compilation:  */
    "allowJs": true,                          /* Allow javascript files to be compiled. */
    // "checkJs": true,                       /* Report errors in .js files. */
    "jsx": "react-native",                    /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */
    // "declaration": true,                   /* Generates corresponding '.d.ts' file. */
    "sourceMap": true,                        /* Generates corresponding '.map' file. */
    // "outFile": "./",                       /* Concatenate and emit output to single file. */
    "outDir": "./build",                      /* Redirect output structure to the directory. */
    "rootDir": "./src",                       /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */
    "removeComments": false,                  /* Do not emit comments to output. */
    // "noEmit": true,                        /* Do not emit outputs. */
    // "importHelpers": true,                 /* Import emit helpers from 'tslib'. */
    // "downlevelIteration": true,            /* Provide full support for iterables in 'for-of', spread, and destructuring when targeting 'ES5' or 'ES3'. */
    // "isolatedModules": true,               /* Transpile each file as a separate module (similar to 'ts.transpileModule'). */

    /* Strict Type-Checking Options */
    "strict": true,                           /* Enable all strict type-checking options. */
    "noImplicitAny": true,                    /* Raise error on expressions and declarations with an implied 'any' type. */
    "strictNullChecks": true,                 /* Enable strict null checks. */
    "noImplicitThis": true,                   /* Raise error on 'this' expressions with an implied 'any' type. */
    "alwaysStrict": true,                     /* Parse in strict mode and emit "use strict" for each source file. */

    /* Additional Checks */
    // "noUnusedLocals": true,                /* Report errors on unused locals. */
    // "noUnusedParameters": true,            /* Report errors on unused parameters. */
    // "noImplicitReturns": true,             /* Report error when not all code paths in function return a value. */
    // "noFallthroughCasesInSwitch": true,    /* Report errors for fallthrough cases in switch statement. */

    /* Module Resolution Options */
    "moduleResolution": "node",               /* Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6). */
    // "baseUrl": "./",                       /* Base directory to resolve non-absolute module names. */
    // "paths": {},                           /* A series of entries which re-map imports to lookup locations relative to the 'baseUrl'. */
    // "rootDirs": [],                        /* List of root folders whose combined content represents the structure of the project at runtime. */
    // "typeRoots": [],                       /* List of folders to include type definitions from. */
    // "types": [],                           /* Type declaration files to be included in compilation. */
    "allowSyntheticDefaultImports": true      /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */

    /* Source Map Options */
    // "sourceRoot": "./",                    /* Specify the location where debugger should locate TypeScript files instead of source locations. */
    // "mapRoot": "./",                       /* Specify the location where debugger should locate map files instead of generated locations. */
    // "inlineSourceMap": true,               /* Emit a single file with source maps instead of having a separate file. */
    // "inlineSources": true,                 /* Emit the source alongside the sourcemaps within a single file; requires '--inlineSourceMap' or '--sourceMap' to be set. */

    /* Experimental Options */
    // "experimentalDecorators": true,        /* Enables experimental support for ES7 decorators. */
    // "emitDecoratorMetadata": true,         /* Enables experimental support for emitting type metadata for decorators. */
  },
  "include": [
    "src/**/*",
    "./node_modules/react-native-dev-kit/**/*"
  ],
  "exclude": [
    "__tests__",
    "index.android.js",
    "index.ios.js",
    "build",
    "local_history",
    "node_modules"
  ]
}

閉じたファイルからエラーが表示されないのはなぜですか（エラーがあると確信しています）？

👍

@appersideが言ったように、タスクはファイルが変更されたときにのみエラーを表示します。

エラーがサイドバーのワークスペースに表示されるという新機能により、箱から出して作業することができれば幸いです。

最新バージョンのvscodeでは、タスク形式が少し変更されたようです。 新しい形式は次のとおりです。

        {
            "label": "Monitor TS Errors",
            "command": "./node_modules/.bin/tsc",
            "type": "shell",
            "args": ["--watch", "--project", "."],
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": false,
                "panel": "shared"
            },
            "isBackground": true,
            "problemMatcher": "$tsc-watch"
        }

VSCodeを開くたびにタスクを開始しますか？ または、自動的に起動する方法はありますか？

最新バージョンのVSコードは、ファイルごとのエラー数を示していると思います

これを無効にするにはどうすればよいですか？

//ファイルとフォルダにエラーと警告を表示します。
"problems.decorations.enabled"：true、

単にこれをfalseに入れてください;）

木、1：36 AMで2018年2月15日、pabloliに[email protected]書きました：

これを無効にするにはどうすればよいですか？

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/13953#issuecomment-365838054 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAy0aayEHkVuxumJRuZz-mdWmBvBhdn9ks5tU9B2gaJpZM4KaH3J
。

これは私が使用しているものです

{
  "label": "TSCompileAll",
  "type": "shell",
  "command": "./node_modules/.bin/tsc --watch --noEmit --project .",
  "problemMatcher": ["$tsc-watch"]
}

それはかけがえのないものです、それがデフォルトまたは少なくとも設定にされることができるかどうか疑問に思います。

ワークスペースまたはプロジェクトでこのタスクを自動開始することは可能ですか？

私はこれを使用します：

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "tsc watch",
            "type": "shell",
            "command": "./node_modules/.bin/tsc",
            "isBackground": true,
            "args": ["--watch", "--noEmit", "--project", "www"],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "presentation": {
                "reveal": "never",
                "echo": false,
                "focus": false,
                "panel": "dedicated"
            },
            "problemMatcher": "$tsc-watch"
        }
    ]
}

この拡張機能を使用して、起動時にタスクを実行します： https ：

ファイルを閉じるときに（問題パネルで）ファイルのエラーを保持する方法がまだわかりません。

ファイルを閉じた後もパネルにリストされている問題を保持するオプションがあると非常に役立ちます。

誰かがこの問題の回避策を持っていますか？ 中規模から大規模のプロジェクトの場合、エラーが存在しないことを確認するためにすべてのファイルを開くのは非常に面倒な場合があります。

1つのコマンドですべてのファイルを一度に開く方法はありますか？ それは私にとって許容できる回避策です。

@daarongプロジェクト全体をチェックするためにvscodeでコーディングしている間、私は通常、ターミナルでeslint-watchを実行しています。 vscodeにすべてのリンティング情報があるほど良くはありませんが、プロジェクト内のファイルにエラーがあるかどうかを一目で確認するための適切なフォールバックです。

誰かがJavaファイルのこれに対する回避策を持っていますか？
開いているファイルのエラーだけでなく、問題パネルのすべてのファイルのすべてのエラーをいつでも確認したい。

これは冗談ですか？ 約2,000個のファイルがあり、それらすべてを手動で開いてlintエラーを検索する必要がありますか？

vsコードでtslintをトリガーする方法はありますか？ 私はeを使うことができました。 tslintを使用して、コンソールに表示します。
VS Codeをトリガーして、srcフォルダー内のすべてのファイルのエラー（構文とリンター）をスキャンできれば素晴らしいと思います。
言い換えると、srcフォルダー内のすべてのファイル（ts）を同時に開くにはどうすればよいですか？

node_modulesのような他のフォルダを検索しないでください。 ...プロトコルのためだけに。 😄
たぶん、パスを含める/除外するオプションがいいでしょうか？ ..。

約1か月前、ワークスペースビューアのファイルの横に小さな赤いアイコンが表示されていました。 今、彼らは去りました、そして、私はそれをどのようにしたのか分かりません。 新しいバージョンのVSCodeが動作方法を変更したか、それを壊す拡張機能をインストールしました。 それを再び機能させる方法は？ 私はtasks.jsonについて聞いたことがなく、それが以前に機能したという事実は、それが現在デフォルトの動作であることを私に示唆しています。

これが、10秒未満ですべての問題を確認する方法です。

あなたはちょっとしたトリックを使います。

ファイル内のすべてを置換を開きます（Ctrl + Shift + H）。

交換 ; と ;

すべて置換を押します。 それでおしまい。 次に、問題を確認します。

ここでの前提は、すべてのファイルに少なくとも1つのセミコロンがあることです。 大規模なプロジェクトの場合、検索を絞り込むように求める警告が表示された場合は、すべてのファイルに共通しているものの、あまり存在しないものを入力するだけです。

これに関する更新はありますか？ Ajayのショートカットは機能しますが、かなりハッキーな感じがします。 これはVSCにとって明白で簡単な勝利のようです。 「すべてのエラーを表示/開いているファイルのエラーを表示」というスイッチがあれば十分です。

これをファイルの変更時に自動的に発生させるのではなく、別の考え。 下部のバーにボタンがあるか、すべてのファイルをチェックする明示的に実行できるコマンドがあれば、まったく問題ありません。

正解です。問題は、開いているすべてのファイルをチェックするTSサービスの調整と、閉じられていて通常は自動的にチェックされないファイルのチェックに関係していると思いますが、それは正しいですか？ したがって、簡単な解決策は、問題ペインが単一のソースからすべてのTS問題を確実に受け取るようにすることです。それは正しいですか？

問題がvscodeチーム（？）によってどのように解決されないかを見て、提案：

アドオンまたはvscodeタスク問題マッチャーを介してこれを解決することは不可能ですか？ それなら、問題ペインに何がいつ表示されるかを自分で確認できるからですか？ 次に、vscodeがその内容を表示しないようにする必要がありますか？ vscodeの開発者は、このようなものが実行可能かどうかを教えてもらえますか？

ただし、この基本的なものはvscode自体で処理する必要があると思います。 ファイルを閉じるときにTSエラーが自動的に解決するわけではありません...開いているかどうかに関係なく、TSサーバーにすべてのファイルを処理させるだけでうまくいくはずです。 もちろんオプションである必要がありますが、オプションである必要があります。

これが最初に解決するすべての問題の中で最も重要ではないのはなぜですか？ IDEは修正されるまで壊れています。

さて、これはハッキーなソリューションです。
タスクに$ tsc-watchを使用させることにより、 @ plievoneのソリューションを使用します。 次に、AutoLaunchなどのプラグインを入手して、Visual StudioCodeを開くたびにタスクを実行します。 （https://marketplace.visualstudio.com/items?itemName=philfontaine.autolaunch）

@mateuscbの提案を拡張するには、ファイルエクスプローラーのコンテキストメニューで、特定のフォルダーを右クリックして「フォルダー内の問題を検索」を実行できるものが適している可能性があります。ユーザーは、スコープと速度の間のトレードオフを決定します。

@ ajayRaghav37の提案をしないでください
くそー、私は将来二度とtsコードを書くつもりはない）

これがいつパイプラインに入れられるかについての更新やアイデアはありますか？ この機能をすぐに使用できると便利です。

ES-Lintは、VSCodeに新しいタスクを導入しました。 ワークスペースの設定で有効にする必要があります。

"eslint.provideLintTask": true

ターミナルメニューに移動し、タスクの実行を選択してから、

eslint：フォルダ全体をリントします。

ターミナルで次のコマンドを実行して、ほとんどの問題を自動修正することもできます。

.\node_modules\.bin\eslint.cmd --fix .

参照： https ：

VS Codeで問題のあるスキャナーをまだ待っていますが、eslintを使用する場合は、これで十分です。

確かに、大規模なプロジェクトには多くの機能が必要でした。 更新はありますか？

@ ajayRaghav37 、eslintは入力エラーをキャッチできず、ルールをリントするだけのようです。

https://github.com/typescript-eslint/typescript-eslint/issues/36#issuecomment -478820127

+1

これまで。 また、組み込みのTSチェックとリンティングを無効にして、ビルドタスクの結果を使用することも可能であると思います。

+1

この問題を解決するためにtsc --noEmit -wを実行します。

しかし、VSCodeとts-serverを共有する方が良いと思います。

しかし、なぜこれほど長い間実装されていないのでしょうか。

ここでTS言語サーバーに精通している人はいますか？ LSP APIには、これをIDEに伝達する方法がありませんか？ これはパフォーマンスの問題ですか？ 明らかに人々はこの機能の欠如に情熱を注いでいるので（私はそうです）、これをフィニッシュラインを通過させるためのコミュニティの支援に関心があると思います。

しかし、それは、ここでの問題がVSCodeチームの人的資源の不足だけである場合です。

問題が異なる場合（VS Codeアーキテクチャへの大きな影響、LSPへの変更が必要、パフォーマンスへの影響が不明確、UXの考慮事項）、これを知っていると、この一見単純な機能に非常に時間がかかる理由を説明するのに役立ちます。

この号には、Visual Studio Codeチームではなく、TypeScriptチームに対する責任についてさまざまなコメントがあります。 しかし、これはVSCodeに組み込まれている「@ ts-check」機能の問題でもあります。 この投稿で言及されている「tsc」コマンドを実行するタスクを使用するための回避策は、tscがインストールされていないため機能しません（@ ts-checkとjsdocのみを使用しています）。

以前は、プロジェクト内のすべてのファイルをクリックしてエラーを見つけていました。 それは面倒でしたが、ファイルを閉じても、少なくとも問題はサイドバーから消えませんでした。 過去数か月の更新の1つの後、この問題が発生しました：＃73153。

これが最初に解決するすべての問題の中で最も重要ではないのはなぜですか？ IDEは修正されるまで壊れています。

同意します。

いつ？

上記の「承認された」ソリューションは機能しますが、一部のフィールドは非推奨になっています。

{
      "label": "Watch TS Errors",
      "type": "shell",
      "command": "tsc",
      "args": ["-w", "-p", ".", "--noEmit"],
      "isBackground": true,
      "problemMatcher": "$tsc-watch"
}

私のために働きます。

まだ持っていない場合は、tasks.jsonファイルの作成についてはhttps://code.visualstudio.com/docs/editor/tasksも参照して

このようなビルドタスクとしてtscを実行しているときに、VS Codeの組み込みTSサーバーを無効にすることは可能ですか？ 私が尋ねる理由は、そうしないと、組み込みのTSサーバーからのエラーとタスクからのエラーの2つのセットのエラーが発生し、同期がとれていない場合があるためです。

IDEは壊れており、Typescriptプロジェクトでの作業には使用できません。 したがって、バージョン1.28.2に固執し、更新を無効にする必要があります。

奇妙なことですが、以前はどういうわけかうまくいきました。 何が起こったか？ そして、それはいつ再び機能しますか？ すでに1年が経過し、変化の兆しはありません...

2019年10月、これはまだ大規模です。

他のIDEが提供する機能の3年.... NNNNICCCEEEEEEEEEEEEEE

他のIDEが提供する機能の3年.... NNNNICCCEEEEEEEEEEEEEE

VSCodeはIDEではないことに注意してください。 これは、エディターとIDEの間の何かです。
とにかく、私は彼らがそれをすることを望みます

他のIDEが提供する機能の3年.... NNNNICCCEEEEEEEEEEEEEE

VSCodeはIDEではないことに注意してください。 これは、エディターとIDEの間の何かです。
とにかく、私は彼らがそれをすることを望みます

誰も気にしない。 それでも、tsファイルをチェックするためにいまいましいタスクを実行することさえできません。

提供されたガイドは、まったく新しいクソプログラミング言語を学んでいるようです。
私たちは仕事と生産を行っています。私は、自分のtsファイルをIDE（I CALL IT IDE ok？）でチェックするスクリプトを作成するために、でたらめのすべてのWebpack（および同様のツール）の時流を学ぶのに無駄な時間はありません。 tは、IDEの同じ作成者が正しく作成した言語もサポートしています。

なんてでたらめ

なんてでたらめ

少し見方をすれば：

マイクロソフトはいくつかのソフトウェアを作成し、それを無料で提供しました。
このソフトウェアは、それに感謝している何百万もの人々に役立ちます。
マイクロソフトは、このソフトウェアの使用を強制していません。

理論的には完璧ではないので、無料で何かを提供してくれることに腹を立てています。

また、彼は同じ「IDE」の言語を使用しており、IDEはオープンソースであり、プルリクエストを受け入れます...

私はこれを長い間見ていましたが、エラーや警告を追跡するためのより良い方法をまだ待っていて、一般公開以来使用しています。

そうは言っても、私の意見では、VSCodeは間違いなくJS / TS開発に最適なIDEです。つまり、Githubに次ぐ最高のMS製品でさえあるかもしれません。 機能とパフォーマンスは確実に改善されており、拡張機能の量が非常に多いので、とてもうれしく思います。 はい、ドキュメントの方が優れている可能性がありますが、そこにあるすべての技術ドキュメントについてそれを言うことができます。

VS Codeチームは、より優れたツールと統合を実現するために常に懸命に取り組んでいると確信しています。

そして、私たちはまだ新しい機能を要求したり、これを丁寧に増やし続けることができると信じています。

回避策への追加-tsc-wの出力を監視するための事前構成されたタスクがあるようです。 Macの場合、[ターミナル]-> [タスクの構成...]-> tsc：watch-tsconfig.json。 次に、ctrl + shift + Bを押して、タスクを実行します。

3年後...何かニュースはありますか？

大規模なリファクタリングの最中。 影響を受けるすべてのファイルを閉じると、すべてのエラーが表示されなくなることに気づきませんでした:-(

3年とまだ開いています：ダンサー：

3年とまだ開いています

うん、ばかからのランダムな反対票。

とにかく、これは厄介な問題です!!! 深刻なビジネスプロジェクトに何百ものファイルがあることに気づきましたか？
念頭に置いて、どのようにそれらを追跡することになっていますか？

これは、人々がIDEを使用するための基本的な機能の1つです。

そして今、それはビジュアルスタジオとそのインテリセンスにも時々伝播しているようです

ところで、タスクは少なくともそれを軽減するようであり、tsファイルの場合はいくつかの制御スクリプトも利用できるようです。 vscodeの拡張機能マネージャーからすべてのangular / typescript拡張機能によってインストールされるかどうかはわかりませんが、タスク検索バー（[ここ]に表示）（https://code.visualstudio.com）で検索する場合/ docs / editor / tasks）あなたはあなたがコンパイルするたびにトリックをする時計のようなものまたはそのようなものを検索することができます（それは別のタスクでもある通常のコンパイルプロセスと一緒にそれを行うようです）

このため、[問題]タブは役に立たないので、使用しません。 代わりに、ターミナルでコマンドを実行して、実際に必要なものを取得します。 たとえば、プロジェクトのすべてのコンパイラエラーが発生した場合、 tsc -wを実行します。 プロジェクトのすべての問題を確認したい場合と、まったく確認したくない場合があります。 ファイルが開いているかどうかは関係ありません。 それは無関係です。

さて、誰かがProblemsタブで開いているファイルについてのみエラーを表示することが非常に重要である場合は、それを許可します。

ただし、Visual Studioの場合と同じように、別のタブ、たとえばBuild Outputを作成してください。

このタブには、コンパイラからのエラーと警告が単純な1行のテキストとして表示され、ダブルクリックするとファイルが開き、エラーのある行にキャレットが配置されます。

また、 F4 / Shift-F4ショートカットは、次/前のエラーにジャンプするのに最適です（ただし、これはそれほど重要ではありません）

このタブを完全にクリアし、コンパイルするたびにもう一度入力してください。 それで十分でしょう。

または、誰かがこれの拡張機能を作成できるでしょうか？

「一致するファイルを開く」拡張子を使用して、すべての.tsファイルを開きます。 それは少しパフォーマンスが重いですが、少なくともそれは仕事を成し遂げます。

タイプスクリプト言語サーバーがシングルスレッドであり、C＃のコンパイラのように動作しないためだと思います
ファイルを開いて、コマンドpalete with＃を使用して名前でタイプを検索しようとすると、何も起こらないため、この機能をまだ待っています😞

エッジで生きたい人のために、次のVS Codeインサイダービルドでは、実験的なプロジェクト全体のエラーレポートを可能にする"typescript.tsserver.experimental.enableProjectDiagnostics"設定が導入されています

これは本番環境に対応していないことに注意してください。 大規模なプロジェクトのパフォーマンスの問題がわかっており、インテリセンスが損なわれる可能性があります

この設定の使用中に問題が発生した場合は、新しい問題を開いてください

エッジで生きたい人のために、次のVS Codeインサイダービルドでは、実験的なプロジェクト全体のエラーレポートを可能にする"typescript.tsserver.experimental.enableProjectDiagnostics"設定が導入されています

これは本番環境に対応していないことに注意してください。 大規模なプロジェクトのパフォーマンスの問題がわかっており、インテリセンスが損なわれる可能性があります

この設定の使用中に問題が発生した場合は、新しい問題を開いてください

お疲れ様でした〜

この機能の進捗状況はどこで確認できますか？ 準備ができたら、VSコードの標準版に追加されるのを心待ちにしています。

エッジで生きたい人のために、次のVS Codeインサイダービルドでは、実験的なプロジェクト全体のエラーレポートを可能にする"typescript.tsserver.experimental.enableProjectDiagnostics"設定が導入されています

これは本番環境に対応していないことに注意してください。 大規模なプロジェクトのパフォーマンスの問題がわかっており、インテリセンスが損なわれる可能性があります

この設定の使用中に問題が発生した場合は、新しい問題を開いてください

Visual StudioCodeのすばらしい作業に貢献してくれたすべての人に感謝します。

エッジで生きたい人のために、次のVS Codeインサイダービルドでは、実験的なプロジェクト全体のエラーレポートを可能にする"typescript.tsserver.experimental.enableProjectDiagnostics"設定が導入されています

これは他のリンターとどのように連携しますか？

"typescript.tsserver.experimental.enableProjectDiagnostics"を有効にすると、Typescriptリンターが最終的にnode_modulesをトラバースし、 "exclude"場合でも、配布ファイルから何百ものエラーを掘り起こすといううさぎの穴を掘り下げるという問題がありました。 tsconfig.jsonは"node_modules"が含まれています。 これをデバッグする方法がよくわかりません。

また、@ vdhと同じ効果が得られます。VSCodeはnode_modulesフォルダー全体を解析し、各ファイルに対してeslintを実行します。

私のeslint / editor構成は次のとおりです。

    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": true
    },
    "eslint.validate": [
        "javascript",
        "javascriptreact",
        "typescript",
        "typescriptreact"
    ],
    "[javascript]": {
        "editor.formatOnSave": false
    },
    "[javascriptreact]": {
        "editor.formatOnSave": false
    },
    "[typescript]": {
        "editor.formatOnSave": false
    },
    "[typescriptreact]": {
        "editor.formatOnSave": false
    },
    "eslint.enable": true

少なくともオンセーブアクションでは、パスにnode_modulesを含むファイルはすべて無視する必要があるというのが、ビジネスの最優先事項のようです。

これは非常に高く評価されている機能です。
@ Martaver @ vdhと同じ動作をし
フィルタを追加して、今のところ「解決」しました

!*node_modules, !*.vscode

ターミナルビューに。 （視覚的にのみ異なります）。 誰かがこれで遊ぶことに興味がある場合に備えて。

@ blackfan23は、敷物の下でほこりを掃除するのに少し似ているようです：D

@Martaver同意しました。 何かのようなもの：

"typescript.tsserver.experimental.enableProjectDiagnostics.ignores": [
  "**/node_modules/**"
]

理想的です。 実際には0であるのに、プロジェクトで1,000を超える問題を確認するのはちょっとくだらないことです。

@ blackfan23 node_modulesへの急降下によって引き起こされたすべての過剰なCPUチャーンのため、これはオプションではありません

@vdh tsconfigでskipLibCheckをtrueに設定すると、[問題]タブでnode_modulesからのエラーが表示されなくなりました。

ただし、このスタックオーバーフロースレッドに基づいて、このオプションをオンにすると、タイプチェックが低下します。 VSコードまたはtypescriptチームの誰かが、このオプションをオンにすることの長所と短所に光を当てることができるかどうかを評価してください。

@mjbvz
よく働く！ ありがとう！
これらのエラーに対して1つのコマンドで「すべて修正」を実行できますか？

Typescriptではなく他の言語はどうですか？ たとえば、プロジェクトには数百のPHPファイルがあり、個々のファイルのIntellephense拡張機能によって報告された問題を確認できますが、本当に必要なのは、ワークスペース全体の診断を実行することです。

はい、これにより、ESLintがnode_modules同じ問題を引き起こしている場合にも問題が発生します（「ESLint：構成のロードに失敗しました」は、そこにあるディレクトリをトロールします）。 リンターごとにこのバグにパッチを当てようとするのではなく、ブラックリストなどが本当に必要です。

node_modulesを除外すると、修正は1つになりません:)

これはブートで機能するようですが、-あなたのマイレージは異なる場合があり、もちろん、保証はありません：

package.jsonにtypescript3.9.2があり、VSCodeのワークスペースからそのバージョンを選択した場合：

1. https://www.npmjs.com/package/patch-package

2. ： ./patches/typescript+3.9.2.patch

diff --git a/node_modules/typescript/lib/tsserver.js b/node_modules/typescript/lib/tsserver.js
index 2b6f035..ac6c9b4 100644
--- a/node_modules/typescript/lib/tsserver.js
+++ b/node_modules/typescript/lib/tsserver.js
@@ -149353,7 +149353,7 @@ var ts;
                     return;
                 }
                 // No need to analyze lib.d.ts
-                var fileNamesInProject = fileNames.filter(function (value) { return !ts.stringContains(value, "lib.d.ts"); }); // TODO: GH#18217
+                var fileNamesInProject = fileNames.filter(function (value) { return !ts.stringContains(value, "lib.d.ts") && !ts.stringContains(value, "node_modules"); }); // TODO: GH#18217
                 if (fileNamesInProject.length === 0) {
                     return;
                 }

1. npm installまたはyarn
2. VSCodeを再起動します

=利益？

@mjbvzこれを有効にしてみましたが、オフにした場合と比較して、「コードヘルパー（レンダラー）」プロセスのCPU使用率がかなり高くなっています。 これは関連しているように思われますか（プロセス名の「レンダラー」はそうではないことを示唆していますが、私はそれを数回切り替えました）。 プロジェクトは巨大ではありません（https://github.com/Dart-Code/Dart-Codeです）。

それは永遠に続くわけではありませんが、それは私のMacBookファンを十分に回転させ、今はおそらくオンではなくオフにしておくでしょう。

node_modulesを回避するためにリンター構成を設定しようとして失敗したさまざまな試みにもかかわらず、 "typescript.tsserver.experimental.enableProjectDiagnostics"常にnode_modules内のすべてのファイルに飛び込む理由について、これまでに調査がありましたか？

この潜在的に素晴らしい機能は、不要なファイルやディレクトリを繰り返すことによって引き起こされる過度のCPUチャーンによって完全に殺されるため、残念です…😢

PROBLEMSパネルに表示されるnode_modulesからのTypeScriptエラーで上記の@vdhと同じ問題が発生しています-バグを報告するかどうか、またはそれが単なるミスであるかどうかは

次のようなさまざまなtsconfig.json設定を試しました。

"exclude": ["node_modules", "./node_modules/*"],

問題が発生するかどうかにパターンがあるかどうかはよくわかりません。 私が疑ういくつかのことが起こっている/起こっていた：

• ランダムに行き来しているように見え、vscodeを再起動すると少しは役に立ちましたが、後で戻ってきます。
• 一部のプロジェクトに他のプロジェクトよりも影響を与えるように見えました。
• 現在問題が発生していないので、最近の更新で何かが修正された可能性がありますか？ 私はまだインサイダー版を実行しています。

上記の点については完全にはわかりませんが、私が混乱しているだけかもしれません。 関連する可能性のある別の逸話を追加するだけです。 現在のバージョンでまだ問題が発生している人が数人いる場合は、新しい問題を提出する価値があるかもしれません。 まだそれをしていませんが、私はそれについてよくわかりません。

同じ問題が発生し、＃90430での解決策はtypescript-tslint-pluginを使用すること

@enko TSLintは2019年以降、ESLintを優先して非推奨になりました。非推奨のリンターのプラグインを推奨することは、この問題の適切な解決策ではありません。

typescript.tsserver.experimental.enableProjectDiagnosticsを無効にする必要がありました

"editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }

非常に遅い（ 1つのファイルを保存するのに2分）。

また、node_modulesからのランダムなTSエラーが表示/非表示になっていることに気づきました。

タスクでapplyTo適切に設定すると、実際には回避策があります。

現在表示

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "tsc watch",
      "type": "shell",
      "command": "tsc",
      "isBackground": true,
      "args": ["--build", "--watch"],
      "group": {
        "kind": "build",
        "isDefault": true
      },
      "presentation": {
        "reveal": "never",
        "echo": false,
        "focus": false,
        "panel": "dedicated"
      },
      "problemMatcher": {
        "base": "$tsc-watch",
        "applyTo": "allDocuments"
      }
    }
  ]
}

@ samesfahani-tuplehealthコメントを編集して、このタスクがenableProjectDiagnosticsに直接関連していることを伝えるか、修正で

@vdhまあまあ、編集済み。 この問題は特にenableProjectDiagnostics前後ではないと思いますが、 当面の問題は、現在表示されていないファイルであっても、プロジェクト全体の問題を表示できないことでした。

不要なnode_modulesエラーの問題に関して、具体的に説明する新しい問題を作成しました： https ：

@vhd / @martaver / @ blackfan23 / @SupremeTechnopriest / @patroza / @jgoux /他の誰か...その問題にさらに手がかりを追加していただければ、うまくいけばこれを解決するのに役立つかもしれません。

@jgouxと同じ問題で、 "source.fixAll.eslint": trueでは機能しません-eslintは、開いているファイルだけでなく、プロジェクト内のすべてのファイルのチェックを開始し、変更のたびにプロジェクト全体を再チェックします。 VSCodeがハングします。 なぜデフォルトのESLintの動作を変更するのかわかりませんが、それは本当にブロッカーです

「typescript.tsserver.experimental.enableProjectDiagnostics」は実際に修正および改善する必要があります。 これにより、typescriptが以前よりもはるかに強力になります。

@ samesfahani-tuplehealthによって投稿されたソリューションは非常にうまく機能します。 これは、インポートされたタイプをあるファイルから別のファイルに移動し、インポートが壊れた場所を見つける必要がある場合に非常に重要です。 CPUの使用率は高くありませんが、必要なときに実行できます。

@phatmannこれは回避策であり、解決ません。 機能をバイパスし、代わりに_別のまったく異なる機能_を使用することは、パフォーマンスの問題を修正する方法ではありません。 私はこれについて固執するのは嫌いですが、この素晴らしい（しかし実験的な）機能を修正することから注意を引くノイズの束を持ちたくありません。 それがそれに値する注目を集めれば、それは信じられないほど役に立つものになるかもしれません。

@Vdhあなたはもちろん正しいです。 （実際、タスクのより単純なバージョンである組み込みのtsk：watchタスクは、回避策としても同様に機能します）。 私の混乱はこれです：回避策は非常に効果的かつ効率的であるため、この号で参照されている実際の機能は必要ないと感じています。 私は何かが足りないのですか？

@phatmann Typescriptウォッチタスクを実行したい場合は、すでに実行できます。 これは、TSチェックを実行するだけではありません。 すべてのプロジェクトファイルに対してVSCodeの

現在の唯一の大きな欠陥は、 node_modulesような通常は禁止されているフォルダを含め、文字通りすべてのファイルを実行することで行き過ぎてしまうことです。

vscodeで何かを行う方法を検索するその瞬間、しかしあなたが得るのは4年間の未解決の問題です...😢

どのくらいのお金とどこに送金しますか？

CPUの問題や、node_modulesのスキャンに関するこの機能の問題がある場合は、次のものが含まれていない限り、リポジトリのルートのような場所に共有または「ワークスペース」 tsconfig.jsonないことを確認してください。

"files": []

それ以外の場合、デフォルトでは、tsconfigを含むフォルダーまたはその下にあるすべてのTypeScriptファイルが含まれるため、分析するファイルが多すぎる可能性があります。

この機能は、糸のワークスペースと複合タイプスクリプト「プロジェクト」を使用する大規模なモノレポでうまく機能しています。

素晴らしいアドバイス@dinofx。 さらに、ドキュメントに従って、 files代わりにincludeとexcludeを使用できます。

      "include": ["src/**/*"],
      "exclude": ["node_modules", "test/**/*"],

それは正しいですが、「インクルード」グロブと一致しないものを除外する必要はありません。

"files": []は、「ワークスペース」tsconfig.jsonファイル（他のtsconfig.jsonファイルの束を参照するだけのファイル）の場合はより簡潔です。 十分に文書化されていませんが、パッケージとワークスペースの構成ファイルにtsconfig.jsonという名前を付ける必要があります。そうしないと、多くの機能が正しく機能しません（この機能、参照の検索、リファクタリングなど）。

拡張された共有構成の場合は、 tsconfig.browser.json 、 tsconfig.node.jsonなどの名前を付けることをお勧めします。この名前を付けると、 "files"や"includes"気にする必要がなくなります。

@dinofxファイルトラバーサルの問題は