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）和所有错误和警告在问题视图中正确显示。 这是一个非常好的工作流程，因为语言服务器会立即注意到打开文件的更改，但是 save 会触发增量编译（使用tsc --watch ），这仍然需要一段时间，但我可以通过保存/不保存来控制延迟然而。

关于这个的任何预计到达时间？ 该功能存在很多问题，不确定我是否遗漏了什么 :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) 的语义历史功能来防止“我的终端和 VS Code 之间的有趣舞蹈”。 当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的解决方案，我也只能从打开的文件中看到错误:(。
我看到在输出选项卡中运行的任务，但没有显示任何错误

任务.json：

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

配置文件

{
  "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”：真，

只需将其设置为 false ;)

2018 年 2 月 15 日星期四上午 1:36，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 :

我仍然不知道如何在关闭文件时保留文件的错误（在问题面板中）。

选择在关闭文件后保留面板中列出的问题将非常有帮助。

有人有解决此问题的方法吗？ 对于大中型项目，打开每个文件以确保不存在错误可能非常麻烦。

有没有办法用一个命令一次打开所有文件？ 这对我来说是一个可以接受的解决方法。

@daarong我通常在终端中运行eslint-watch ，而我在 vscode 中编码以检查整个项目。 它不如在 vscode 中包含所有 linting 信息那么好，但它是一个不错的后备，可以一目了然地查看项目中的任何文件是否有错误。

有没有人有针对 java 文件的解决方法？
我想随时查看问题面板中所有文件的所有错误，而不仅仅是打开文件的错误。

你在开玩笑吗？ 我有大约 2,000 个文件，我应该手动打开所有文件以搜索 lint 错误吗？？？

有没有办法在 vs 代码中触发 ts lint？ 我可以用e。 tslint将其显示在控制台中。
如果我可以触发 VS Code 扫描 src 文件夹中的所有文件以查找错误（语法和 linter），那就太好了
换句话说：如何同时打开 src 文件夹中的所有文件（ts）？

不要在 node_modules 等其他文件夹中搜索。 ... 只是为了协议。 😄
也许包含/排除路径选项会很好？ ...

大约一个月前，我在工作区查看器中的文件旁边出现了红色小图标。 现在他们走了，我不知道我是怎么做到的。 要么是新版本的 VSCode 改变了它的工作方式，要么我安装了一个破坏它的扩展。 如何让它再次工作？ 我什至从未听说过tasks.json 并且它以前工作的事实向我表明它现在是默认行为。

以下是您可以在 10 秒内查看所有问题的方法。

你使用一个小技巧。

打开替换所有文件（Ctrl + Shift + H）。

代替 ; 和 ;

点击全部替换。 就是这样。 现在，检查问题。

这里的假设是所有文件都至少有一个分号。 对于较大的项目，如果您收到要求您优化搜索的警告，只需输入所有文件中常见但不常出现的内容。

这事有进一步更新吗？ 虽然 Ajay 的捷径工作感觉相当hacky。 对于 VSC 来说，这似乎是一个明显而轻松的胜利。 只需要一个开关“显示所有错误/显示打开文件的错误”。

另一个想法，而不是在文件更改时自动发生这种情况。 我完全可以在底部栏中有一个按钮或一个我可以明确运行的命令来检查所有文件。

这是正确的，我认为问题与协调检查所有打开文件的 TS 服务有关，另一方面检查关闭且通常不会自动检查的文件，对吗？ 因此，简单的解决方案是确保问题窗格从单一来源接收所有 TS 问题，对吗？

看到vscode团队怎么不解决问题（？），一个提议：

难道不能通过插件或通过 vscode 任务问题匹配器来解决这个问题吗？ 因为那样你就可以自己确保问题窗格显示什么以及何时显示？ 然后你只需要以某种方式禁用 vscode 显示它的东西？ vscode 开发人员可以告诉我这样的事情是否可行吗？

但是我仍然认为这些基本的东西应该由 vscode 自己处理。 当您关闭文件时，TS 错误不会自行解决……只要让 TS 服务器处理所有文件，无论是否打开，都应该可以解决问题。 当然应该是一个选项，但它应该是一个选项。

这怎么能不是首先要解决的所有问题中最关键的问题？ IDE 已损坏，直到修复为止。

好的，这是一个hacky解决方案。
通过使任务使用 $tsc-watch 来使用@plievone的解决方案。 然后在每次打开 Visual Studio Code 时获取 AutoLaunch 之类的插件来运行任务。 （https://marketplace.visualstudio.com/items?itemName=philfontaine.autolaunch）

为了扩展@mateuscb的建议，也许文件资源管理器的上下文菜单中的某些内容会很好，您可以右键单击特定文件夹并执行“在文件夹中查找问题”将是一个不错的选择，因为它允许用户决定范围与速度之间的权衡。

不要做@ajayRaghav37 的建议，它会挂起 vscode。
该死，我以后不会再写 ts 代码了）

关于何时将其投入管道的任何更新或想法？ 开箱即用此功能会很棒。

ES-Lint 在 VS Code 中引入了一项新任务。 您必须在工作区设置中启用它。

"eslint.provideLintTask": true

只需转到终端菜单并选择运行任务，然后选择

eslint: lint 整个文件夹。

您还可以通过在终端中运行以下命令来自动修复大多数问题：

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

参考： https :

虽然我们仍在等待 VS Code 中的问题扫描器，但如果您使用 eslint，这是一个足够好的替代方案。

确实是大型项目非常需要的功能。 任何更新？

@ajayRaghav37 ，看起来 eslint 无法捕捉打字错误，只是 linting 规则：

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

+1

上这个。 我还认为应该可以禁用内置的 TS 检查和 linting，只使用构建任务的结果。

+1

我现在运行tsc --noEmit -w来解决这个问题。

但我认为与 VSCode 共享一个ts-server更好。

但是为什么这么久没有实施呢？

这里有人熟悉TS语言服务器吗？ LSP API 是否缺乏将其传达给 IDE 的方法？ 这是性能问题吗？ 显然，人们对缺少此功能（我是）充满热情，因此我认为社区对帮助完成此功能会感兴趣。

但是，如果这里的问题只是 VS Code 团队缺乏人力的话。

如果问题不同（对 VS Code 架构的影响更大，需要更改 LSP，不清楚的性能影响，UX 考虑因素），了解这一点将有助于解释为什么这个看似简单的功能需要这么多时间。

我在这个问题中看到了关于这件事的责任如何由 TypeScript 团队而不是 Visual Studio Code 团队负责的各种评论。 但这也是 VS Code 内置的“@ts-check”功能的一个问题。 这篇文章中提到的使用执行“tsc”命令的任务的解决方法对我不起作用，因为我没有安装 tsc（我只使用 @ts-check 和 jsdoc）。

以前，我过去常常单击项目中的每个文件来查找错误。 这很乏味，但至少在我关闭文件后，问题并没有从侧边栏中消失。 在过去几个月的一次更新之后，引入了这个问题：#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 服务器的错误和来自任务的错误，有时它们不同步。

IDE 已损坏且无法用于处理 Typescript 项目。 所以我必须坚持使用 1.28.2 版本并禁用更新。

奇怪，但它以前以某种方式起作用。 发生了什么？ 什么时候会再次起作用？ 一年过去了，一点改变的迹象都没有……

2019 年 10 月，这仍然逍遥法外。

3 年的其他 IDE 提供的功能...... NNNNICCCEEEEEEEEEEEEEE

3 年的其他 IDE 提供的功能...... NNNNICCCEEEEEEEEEEEEEE

请记住，VSCode 不是 IDE。 这是编辑器和 IDE 之间的事情。
无论如何，我希望他们能做到

3 年的其他 IDE 提供的功能...... NNNNICCCEEEEEEEEEEEEEE

请记住，VSCode 不是 IDE。 这是编辑器和 IDE 之间的事情。
无论如何，我希望他们能做到

谁在乎。 然而，我什至无法启动并运行该死的任务来检查 ts 文件。

提供的指南看起来像是在学习一种全新的该死的编程语言。
我们工作和生产，我没有时间浪费时间学习所有的 webpack（和类似工具）的废话来建立一个脚本来检查我在 IDE 上的 ts 文件（我称之为 IDE 好吗？）甚至支持 IDE 的相同创建者正确创建的语言......

真是胡说八道

真是胡说八道

有点观点：

微软制作了一些软件并免费赠送。
该软件对数百万对其心存感激的人有帮助。
Microsoft 不会强迫您使用此软件。

你对他们免费给你一些东西很生气，因为它没有理论上的那么完美。

此外，他使用相同的“IDE”语言，并且 IDE 是开源的并接受拉取请求......

我已经观察了很长时间，仍在等待更好的方法来跟踪错误和警告，并且自公开发布以来我一直在使用它。

话虽如此，在我看来，VS Code 无疑是 JS/TS 开发的最佳 IDE - 哎呀，它甚至可能是最好的 MS 产品，仅次于 Github。 功能和性能肯定有了改进，大量的扩展让我很高兴。 是的，文档可能会更好，但是您可以对所有技术文档都这么说。

我相信 VS Code 团队一直在努力提供更好的工具和集成。

而且我相信我们仍然可以要求新功能或继续以礼貌的方式提升这个功能。

添加解决方法 - 看起来现在有一个预配置的任务来监视 tsc -w 的输出。 在 Mac 上，终端 -> 配置任务... -> tsc: watch - tsconfig.json。 然后按 ctrl+shift+B 并运行任务。

三年后……有消息了吗？

在大规模重构中。 我没有意识到通过关闭所有受影响的文件，我将不再看到所有错误:-(

3 年，仍然开放 :dancer:

3 年，仍然开放

是的，来自白痴的随机投票。

无论如何，这是一个烦人的问题来吧！！！ 你意识到在一个严肃的商业项目中有数百个文件吗？
我们应该如何记住它们？

这是人们使用 IDE 的基本功能之一......

现在它似乎也在不时地传播到视觉工作室及其智能感知

顺便说一句，任务似乎至少可以减轻它，对于 ts 文件，似乎也有一些控制脚本可用。 我不知道它们是否被 vscode 中的扩展管理器的所有 angular/typescript 扩展安装，但是如果你在任务搜索栏中搜索（显示在 [here]）（https://code.visualstudio.com /docs/editor/tasks) 你可以搜索像 watch 之类的东西，或者类似的东西，每次编译时都能起到作用（似乎它和正常的编译过程一样，这也是另一项任务）

由于这个原因，我发现问题选项卡没用，所以我从不使用它。 相反，我在终端中运行了一些实际给我所需的命令。 例如，如果我运行项目的所有编译器错误tsc -w 。 我要么想查看项目中的所有问题，要么不查看。 我不在乎文件是否碰巧打开。 这无关紧要。

好吧，如果某人只看到Problems选项卡中打开的文件的错误如此重要，那就让它吧。

但是您能否创建另一个选项卡，就像在 Visual Studio 中一样说Build Output 。

此选项卡会将来自编译器的错误和警告显示为简单的单行文本，双击它会打开文件并将插入符号放在错误所在的行上。

另外F4 / Shift-F4快捷方式可以很好地跳转到下一个/上一个错误（但这不是那么重要）

只需完全清除此选项卡并在每次编译后再次填写即可。 那就足够了。

或者也许有人可以为此创建扩展？

我正在使用“打开匹配文件”扩展名来打开所有 .ts 文件。 它的性能有点高，但至少它完成了工作。

我认为这是因为打字稿语言服务器是单线程的并且不像 C# 的编译器
仍在等待此功能，因为有时我打开文件并尝试使用带有 # 的命令面板按名称查找类型，但没有任何反应😞

对于那些希望生活在边缘的人，下一个 VS Code 内部人员构建引入了一个"typescript.tsserver.experimental.enableProjectDiagnostics"设置，可以启用实验性项目范围的错误报告

请注意，这不是生产就绪！ 它已知大型项目的性能问题，可能会破坏您的智能感知

如果您在使用此设置时遇到问题，请打开一个新问题

对于那些希望生活在边缘的人，下一个 VS Code 内部人员构建引入了一个"typescript.tsserver.experimental.enableProjectDiagnostics"设置，可以启用实验性项目范围的错误报告

请注意，这不是生产就绪！ 它已知大型项目的性能问题，可能会破坏您的智能感知

如果您在使用此设置时遇到问题，请打开一个新问题

干得好~

我们可以在哪里查看此功能的进度？ 当它准备好时，我热切地等待它添加到 VS 代码的标准版中。

对于那些希望生活在边缘的人，下一个 VS Code 内部人员构建引入了一个"typescript.tsserver.experimental.enableProjectDiagnostics"设置，可以启用实验性项目范围的错误报告

请注意，这不是生产就绪！ 它已知大型项目的性能问题，可能会破坏您的智能感知

如果您在使用此设置时遇到问题，请打开一个新问题

感谢 Visual Studio Code 的所有贡献者所做的出色工作。

对于那些希望生活在边缘的人，下一个 VS Code 内部人员构建引入了一个"typescript.tsserver.experimental.enableProjectDiagnostics"设置，可以启用实验性项目范围的错误报告

这如何与其他 linter 一起使用？

我遇到了一个问题，每当我启用"typescript.tsserver.experimental.enableProjectDiagnostics" ，Typescript linter 最终都会陷入遍历node_modules并从分发文件中挖掘数百个错误的兔子洞，即使"exclude" tsconfig.json中的"node_modules"包含

我也得到了与@vdh相同的效果——我的 VSCode 解析了我的整个 node_modules 文件夹，并对每个文件运行 eslint。

我的 eslint/编辑器配置是：

    "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 个问题时，在一个项目中看到超过 1000 个问题真是太糟糕了。

@blackfan23这不是一个选项，因为所有过度的 CPU 流失都是由node_modules

@vdh我设置skipLibCheck在tsconfig为true，“问题”选项卡停止显示来自node_modules错误。

但是，基于此 stackoverflow thread ，启用此选项会降低类型检查的性能。 感谢来自 VS 代码或打字稿团队的人能否阐明打开此选项的利弊。

@mjbvz
效果很好！ 谢谢！
我们可以使用一个命令对这些错误执行“修复全部”吗？

其他语言呢，而不是 Typescript？ 例如，我在项目中有数百个 PHP 文件，我可以看到 Intellephense 扩展为单个文件报告的问题，但我真正想要的是对整个工作区运行诊断。

是的，这也会导致问题，其中 ESLint 对node_modules执行相同的操作（“ESLint：无法加载配置”，因为它在那里拖曳目录）。 确实需要有一个黑名单或其他东西，而不是试图在每个 linter 中修补这个错误。

排除 node_modules 将是一个 no1 修复:)

这似乎可以启动，但是 - 您的里程可能会有所不同，当然，没有保修：

鉴于您的 package.json 中有 typescript 3.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 风扇旋转，以至于我可能会关闭它而不是打开它。

尽管我们多次尝试设置 linter 配置以避免node_modules ，但为什么"typescript.tsserver.experimental.enableProjectDiagnostics"总是潜入node_modules所有文件，到目前为止是否有任何调查？

令人失望，因为这个潜在的很棒的功能被它迭代不需要的文件和目录导致的过度 CPU 流失完全杀死了......😢

我一直在看到上面提到的@vdh相同的问题， node_modules TypeScript 错误出现在PROBLEMS面板中 - 不确定是否报告错误，或者只是一些错误 -我造成的配置问题。

我尝试了各种tsconfig.json设置，例如：

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

我还没有完全弄清楚我是否看到这个问题是否存在某种模式。 我怀疑可能/正在发生的一些事情：

• 它似乎随机来来去去，有时重新启动vscode会有所帮助，但稍后又会回来。
• 似乎比其他项目对某些项目的影响更大。
• 我现在没有看到这个问题，所以也许最近的更新修复了一些问题？ 我仍在运行 Insiders 版本。

对以上几点不完全确定，可能只是我感到困惑。 只是添加另一个可能相关的轶事。 如果我们中的一些人仍然看到当前版本中的问题，可能值得提交一个新问题。 还没有这样做，因为我不太确定其中的任何一个。

我遇到了同样的问题，我在 #90430 中的解决方案是使用typescript-tslint-plugin 。

自 2019 年起， @enko TSLint 已被弃用，而支持 ESLint ，提倡为已

我不得不禁用typescript.tsserver.experimental.enableProjectDiagnostics因为它使

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

非常慢（保存单个文件需要 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 ，或者改写为临时_workaround_ 的建议，而不是修复。 在评论问题线程时，变通方法和实际实际修复之间的区别很重要。

@vdh足够公平，已编辑。 虽然我不认为这个问题特别是在enableProjectDiagnostics ； 手头的问题是我们无法查看整个项目中的问题，即使是当前未查看的文件。

关于不需要的node_modules错误的问题，我创建了一个新问题来专门讨论： https :

@vhd / @martaver / @blackfan23 / @SupremeTechnopriest / @patroza / @jgoux / 其他任何人...如果您可以为该问题添加更多其他线索，它可能有助于解决这个问题。

与@jgoux相同的问题，它不适用于"source.fixAll.eslint": true - eslint 开始检查项目中的每个文件，不仅是打开的文件，而且它会在每次更改时重新检查整个项目。 VSCode 只是挂起。 不知道为什么它会修改默认的 ESLint 行为，但这确实是一个障碍

“typescript.tsserver.experimental.enableProjectDiagnostics”确实应该修复和改进。 这将使打字稿比现在更强大。

@samesfahani-tuplehealth 发布的解决方案非常有效。 当我将导入的类型从一个文件移动到另一个文件并需要找到导入中断的所有地方时，这对我来说至关重要。 我没有看到高 CPU 使用率，但如果是这样，您可以在需要时运行它。

@phatmann这是一种解决方法，_不是_解决方案。 绕过该功能并使用_另一个完全不同的功能_代替_不是解决性能问题的一种方法。 我讨厌坚持这一点，但我宁愿没有一堆噪音来引起人们对修复这个伟大（但实验性）功能的注意。 如果它得到应有的关注，它可能会变得非常有用。

@Vdh你当然是对的。 （事实上​​，该任务的一个更简单版本，内置的 tsk:watch 任务，同样适用于变通方法）。 我的困惑是：解决方法是如此有效和高效，以至于我觉得不需要本期中引用的实际功能。 我错过了什么吗？

@phatmann如果我想运行 Typescript watch 任务，我已经可以做到了。 这不仅仅是运行 TS 检查。 它对每个项目文件运行 VSCode 的所有检查。 Typescript、ESLint、CSpell 等......知道即使我忘记打开文件，我也可以在整个项目中找到错误（无需在所有文件中手动运行每个 linter，甚至可能不得不求助于做它在终端外部）。

现在唯一的主要缺陷是它过度运行几乎每个文件，包括通常禁止的文件夹，如node_modules 。

当你搜索如何使用 vscode 做某事的那一刻，但你得到的是一个 4yo open issue... 😢

我要寄多少钱？寄到哪里？

对于那些有 CPU 问题或此功能扫描 node_modules 问题的人，请确保您没有共享或“工作区” tsconfig.json位于存储库根目录的位置，除非它包括：

"files": []

否则，默认是包含位于包含 tsconfig 的文件夹中或下方的所有 TypeScript 文件，这可能会导致它分析太多文件。

在使用纱线工作区和复合打字稿“项目”的大型 monorepo 中，此功能对我来说很好用。

很好的建议@dinofx。 此外，根据文档，您可以使用include和exclude而不是files 。

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

这是正确的，但没有必要排除与“包含”glob 不匹配的内容。

"files": []对于“工作区” tsconfig.json 文件（只引用一堆其他 tsconfig.json 文件）来说更简洁。 它没有很好的文档记录，但是您需要为包和工作区命名配置文件tsconfig.json ，否则很多功能将无法正常工作（此功能、查找引用、重构等）。

对于扩展的共享配置，最好将其命名为tsconfig.browser.json 、 tsconfig.node.json等。这种命名可以防止任何事情关心"files"或"includes" ，所以你可以省略它们。

@dinofx文件遍历问题不仅限于 Typescript。 此外，并不是每个人都使用 monorepo。