VSCode 是否应该报告从编译中排除的 TS 文件的错误? [英] Should VSCode report errors for TS files that are excluded from compilation?

问题描述

我向 VSCode 提交了这个错误报告，因为我已经排除了*.spec 来自编译的文件，因为我不想在 NPM 发行版中包含这些文件.

I filed this Bug Report with VSCode because I have excluded *.spec files from compilation since I don't want to include the files in the NPM distribution.

我仍然希望看到它们通过 VSCode 工具正确编译.

I would still like to see that they compile correctly though via the VSCode tooling.

目前 VSCode 智能感知报告无法导入路径上可用的导入，这会引发很多错误，将项目规范文件涂成红色等.

As it stands VSCode intellisense reports that imports that are available on the path can't be imported and this throws a lot of errors, paints the project spec files red, etc.

在我的报告中，我说VSCode错误报告和编译应该是两个独立的问题.VSCode 不能同时检查文件是否正确并从编译中排除它.两者并不相互排斥.

In my report, I said that VSCode error reporting and compilation should be two separate issues. VSCode can't both check that the file is correct and exclude it from compilation at the same time. The two are not mutually exclusive.

我已要求从 VSCode 进行分类，但到目前为止该问题仍未解决，但我想看看其他人在 SO 上的内容.是错误还是报告中的结论正确?

I have asked for triage from VSCode, but so far the issue remains closed and I wanted to see what others on SO though. Is it a bug or is the conclusion in the report correct as it stands?

推荐答案

IIUC，现在 VS Code 使用一种语言服务实例来处理 tsconfig.json 未包含的文件(包括 tsconfig.jsoncode>tsconfig.json 根本不存在)带有默认编译器选项，并且当 tsconfig.json 存在时，它使用第二语言服务实例急切地加载所有包含的文件并使用指定的编译器选项.我相信您建议当 tsconfig.json 存在时，第一个语言服务实例应该使用 tsconfig.json 中的编译器选项，但具有与现在相同的文件加载行为.这将略微增加复杂性，老实说，当 tsconfig.json 存在时，编辑从 tsconfig.json 中排除的文件的体验仍然会令人困惑:你的一些文件将看到全局定义，而其他文件则不会，查找所有引用"会给你部分结果.在我看来，你的提议似乎是对现状的一个合理替代，但我不明白你为什么要为此与 VS Code 团队进行斗争，而不仅仅是创建两个 tsconfig.json 文件，这是明确并为您提供您真正想要的统一编辑体验.(或者你是否提议应该有一个单一的语言服务忽略排除并急切地加载项目目录下的所有 .ts(x?) 文件?我很确定这不会飞因为它会在很多情况下导致问题.)

IIUC, right now VS Code uses one language service instance for files not included by tsconfig.json (including the case in which tsconfig.json does not exist at all) with default compiler options, and when tsconfig.json exists, it uses a second language service instance that eagerly loads all included files and uses the specified compiler options. I believe you are proposing that when tsconfig.json exists, the first language service instance should use the compiler options from tsconfig.json but have the same file loading behavior it has now. This would be a marginal increase in complexity, and honestly, the experience of editing files excluded from tsconfig.json when tsconfig.json exists would still be pretty confusing: some of your files will see global definitions and others won't, and "find all references" will give you partial results. Your proposal seems to me to be a plausible alternative to the status quo, but I don't see why you are fighting the VS Code team over it rather than just creating two tsconfig.json files, which is explicit and gives you the unified editing experience you actually want. (Or were you proposing that there should be a single language service that ignores the excludes and eagerly loads all .ts(x?) files under the project directory? I'm quite sure that won't fly as it will cause problems in many scenarios.)

这篇关于VSCode 是否应该报告从编译中排除的 TS 文件的错误?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！