Typescript: 在 Typescript 编辑器中启用 Go to Implementation

因此，如果定义是环境的，那么您希望此功能跳转到相应的.js如果可用），对吗？

@RyanCavanaugh @mousetraps @bowdenk7

因此，如果定义是环境的，那么您希望此功能跳转到相应的 .js（如果可用），对吗？
是的，这是一个对生产力非常有用的场景。 仅此一项就非常有价值。 我相信 atom-typescript 作者相信 Typescript 编译器中的更多钩子会让他更容易实现这一点。 我不清楚这是否是有关 js 实现行号的信息是打字稿编译器通常在内部知道的信息。

此外，另一种情况是启用跳转到应用程序正在使用的库中的原始打字稿 .ts 文件定义。 我想这些信息可以预编译为 d.ts 和 .js 文件。 我们现在有一整套库被写入 .ts 文件作为源输出 ES5 语法 js。 如果能够跳转到 .ts 文件中的原始打字稿实现定义，那就太好了。

我知道这要求更多地跳转到所需库中的 .ts 文件实现，因为它可能需要使用源映射或将源/链接分发到原始 ts 源。 在我看来，生成函数和类的初始库的打字稿编译器会知道实现所在的行，并且可以在库以某种方式分发时保留行号，以便使用该类的应用程序的打字稿编译器可以知道要跳到图书馆的哪一行。

源映射中是否提供有关实现函数/类的行号的信息？ 这些信息还有其他来源吗？

鉴于我们将使用--allowJS标志，语言服务应该能够处理 JS 文件。

我不知道.d.ts文件和.js文件目前在这方面如何协同工作。 @sheetalkamat可能（绝对）比我更了解这一点。

重新打开，因为目前还不支持转到 js 文件

这个有更新吗？ 打字稿的当前状态是您无法跳转到许多著名库中的代码实现。

此问题已多次移动/关闭/重复/重复删除，修复此错误可能会极大地提高生产力。

https://github.com/ubershmekel/vscode-ts-goto-source有一个重现该问题的项目。 如https://github.com/Microsoft/vscode/issues/26325 中所述并在https://github.com/Microsoft/vscode/issues/10806和https://github.com/Microsoft/vscode/issues 中引用

请注意，我不得不从一点使用"typescript.disableAutomaticTypeAcquisition": true来使用 javascript“转到定义”，因为如果找到.d.ts文件似乎会接管。

@DanielRosenwasser 有任何更新吗？ - 对我来说最想要的功能。

如果在完全用 Typescript 编写的 monorepo 中工作，这尤其令人讨厌。 我多次将字段添加到类型或类似的较小更改时使用“转到定义”，添加它，然后发现它再次丢失，意识到我将它添加到.d.ts文件而不是实际的.ts文件

@DanielRosenwasser这有进展吗？ 我真的很喜欢这个功能

同样的问题。 想要“转到实现”到源代码，而不是xx.d.ts

是的，我每天多次错误地在使用 cmd+click 后编辑声明文件，并在代码无法正确运行时最终感到困惑。 特别是因为 src 和 dec 看起来非常相似。 如果有某种方法可以选择我是否要访问声明的源代码，或者如果 VSCode 能够解决这个问题，那将是非常棒的，因为访问源代码总是更可取的恕我直言（如果它可用）。

去采购总是更可取的恕我直言（如果有的话）

当源在 TS 中时。 如果源在 JS 中，尽管有充分的理由去 .d.ts

当源在 TS 中时。 如果源在 JS 中，尽管有充分的理由去 .d.ts

为什么？ 我可以悬停以查看类型定义。 无论如何，类型定义与实现应该有一个单独的命令。

是否有任何原因使这仍然悬而未决？ 解决方法，替代方法或其他什么？ 提前致谢

由于 Typescript 解析器通常从 .ts 实现文件生成 d.ts 文件。 是否可以保留 d.ts 和 .ts 文件之间的关联（可能是带有打字稿编译器选项的输出），以便打字稿编辑器可以将开发人员带到实现类或函数的列表中？

我有一个#21930 的分支，它可以精确地生成这些声明文件源映射（并且将根据请求或在#21930 合并后将其用于审查），并且正在努力为我们的 LS 添加支持以跟踪这些映射。 我们想在 2.8 中发布它。

所以是的，我们一直在努力。 它只需要很多内部变化。 😄

期待有关此问题的更新，以减轻通过手动展开 node_modules 下的文件夹并找到入口模块文件来查找实现的痛苦。

有什么解决方法吗？
由于我们有一个用 ts 编写的用于 db 查询的大模块，因此使用一个命令查看真正的源代码而不是通过 node_modules 搜索会非常好。

@derN3rd有vscode-search-node-modules扩展可以在命令面板中浏览node_modules （而且我还有一个叉子，它总是打开 README vscode-open-node-modules ）

我知道点击要求/导入并打开文件源代码远非完美的用户体验，但绝对比滚动node_modules

@derN3rd我们将在 2.9 中发布--declaratrionMap标志（可能会在下个月发布），并且我们已经启用了通过关联的.d.ts原始源 TS 中的定义它们（如果您在节点模块文件夹中发送声明文件，可能会得到很多您想要的东西）。 我们也在考虑跳转到/从关联的 JS 跳转，前提是正常的源映射也打开。

@weswigham感谢您的快速回复！ 听起来不错
如果该功能已准备好或准备好进行测试，您能否在此处发布更新？

--declarationMap （以及相关的 LS 重定向）自 2.8 版本发布后就一直存在于我们的夜生活中。 我们还没有完成的唯一一点是 JS 文件跳跃，因为这可能需要一些额外的编辑器协调。

关于 3.0-rc 的任何消息？

.css和.json文件的相同问题。 转到定义将我带到.d.ts文件。

import React from 'react'
import Route from 'react-router-dom/Route'
import Switch from 'react-router-dom/Switch'
import Loadable from 'react-loadable'
import  './App.css'
import './tailwind.css'

转到./App.css上的定义将我带到

declare module '*.css' {
    const content: any;
    export default content;
}

declare module '*.svg' {
    const content: any;
    export default content;
}

declare module '*.json' {
    const content: any;
    export default content;
}

VS Code 现在随 TypeScript 3.0.3 一起提供。 有关于这个问题的消息吗？

对我有用（使用 TS 2.9.2 生成的声明映射，运行 VSCode 1.27.0）。 从 API 使用者（在 JS 中实现）导航_转到定义_将我带到 .ts 文件中的实现。

@robsman _Go to Definition_ 应该带你到编译好的 js 代码，而 _Go to Type Definition_ 应该带你到 .d.ts 文件。

你如何使用/包含你编译的模块来打开源文件？

这个问题在 VSCode 1.27.0 中仍然存在，因为这两个函数都将我带到 .d.ts 文件

编辑：我想我误解了你的评论。 它会带你到真正的代码吗？ 如果是这样，您使用的是 monorepo 还是您的编译代码是在自己的 npm 模块中提供的？ 您是否将源文件与编译后的代码一起发送？

@derN3rd重新测试，_Go to Definition_ 和 _Go to Type Definition_ 以及 _Peek Definition_ 都带我到 _.ts_ 文件中的真实代码。

API 声明和实现都位于一个单独的模块中，调用包将其称为 _git+ssh..._ 依赖项。

@robsman我认为Go to Definition应该在node_modules而不是.d.ts内的源js文件（如果它是javascript）中引用“这个”类或函数的来源。 就像它在 Sublime Text 3 中工作一样，我的意思是。 无论如何，我不明白当前状态下 VSCode 这个功能是什么

希望能优先处理这个问题，真的是一个很大的痛点，来自这么多评论和相关问题。

请将我添加到试图使用命令单击来浏览代码的一长串人中。 我的项目中没有 TS 并且我导航到的 npm 包不使用 TS，但是单击 require('co-body') 会将我带到内部生成的 TS 定义。 我是 IntelliJ 的长期用户，因此，我仍然回到 IntelliJ。

这是一个很长的请求

我非常喜欢 VS Code，我刚刚开始了一个新的 Node 项目，并决定第一次使用 TypeScript。 到目前为止，大部分情况都很好，但这个问题一直是一个痛点。 在开源中工作，能够点击依赖项中的真实源代码对工作流程至关重要。 我正在处理 TypeScript 源文件，并使用 JS NPM 模块与没有关联文档的关联@types/xxx模块。 带有 TypeScript 的 IntelliSense 很棒，但并不总是提供足够的信息。 至少，能够从import语句直接单击到模块源会很好。 我相信某些库是有效的，而在其他库中，例如 Passport，我无法通过@types模块中的辅助 TypeScript 存根。

这应该被标记为_Bug_，而不是_Suggestion_。

缺乏代码导航确实破坏了 JavaScript 开发人员的 VSCode 体验。

抱歉给线程发垃圾邮件，但@promaty我现在使用search-node-modules扩展😬

WebStorm 具有相同的行为： StackOverflow ， BugTracker

• VSCode 具有“转到定义”和“转到类型定义”操作

• WebStorm 具有“转到声明”和“转到类型声明”操作

但是当使用 TypeScript 时，两个 IDE 都做同样的事情：总是去类型定义！

“转到定义”和“转到类型定义”在node_modules/库上使用时，都会将我带到.d.ts文件。 在撰写本文时，我使用的是最新的 VS Code（1.34.0）。

例如： npm package @angular/[email protected] ，当我从@angular/core/testing导入TestBed @angular/core/testing并尝试查看TestBed.createComponent的定义时，我得到两个不同的东西：

• “转到定义”-> node_modules/@angular/core/testing/src/test_bed_common.d.ts第 117 行
• “转到类型定义”-> node_modules/@angular/core/testing/src/component_fixture.d.ts第 14 行

这基本上意味着 Angular 源代码在 VS Code 中对我隐藏了😞 我不确定这是否是 Angular 库是如何编写的，或者 TypeScript/VS Code 如何找到源实现的症状。

我所知道的是，我只能在自己的代码中可靠地使用“转到定义”和“转到类型定义”，在这种情况下，我会直接转到源代码； 我从来没有为我自己的代码显示过.d.ts文件。

我们现在必须手动搜索源代码：/

噢，我只是发现 Intellij IDEA 以某种方式使这个功能工作得非常好，即使我在同一个项目中，使用 Typescript 3.0.1

我认为应该提高这个问题的优先级。

我们必须命令 + ,打开工作区设置 -> 取消选中Use Ignore Files -> 删除Search: Exclude: **/node_modules ，并手动搜索源代码。

每天！

所以这就是flow仍然有用的原因。

打字稿团队的某个人能否建议可以在代码中的哪个位置修复？

有趣的是，如果某些包没有可用的类型，“转到类型定义”实际上更适合它。 这意味着如果您喜欢“转到”功能，则不使用类型会更好 😄

这是截屏视频，显示我可以转到没有类型的device包的定义，但是compression引导我进入一些随机类型文件：

https://giphy.com/gifs/j3VCp0LVKr5LsMUh11

@RyanCavanaugh我必须同意其他人的看法，这应该被标记为错误，而不是建议。

就我而言，如果我在自己的代码中定义了类似的东西

const Foo: <T> = () => {
...
}

如果 T 来自 npm 模块，当我尝试转到定义时，它将显示 2 个定义。 我自己的代码和类型定义。 如果我转到类型定义，它会直接转到定义文件。
在第一种情况下，它应该直接进入定义。
为了解决这个问题，我改变了编辑器 --> goto location: multiple 到goto而不是peek

我需要这个功能。 我如何帮助其实施？

请为此+1！

自 2015 年以来，没有解决方案:(

当我们找到.d.ts .ts文件时，OP 询问我们是否可以转到.ts文件与.d.ts文件和声明一起发送由--declarationMaps生成的地图，这是我们当前的行为（所以已经完成了）。 此线程中的 _second_ 请求，即我们现在在此处跟踪的内容，是一个选项，可以转到输出.js文件（例如，如果.ts源不是t 已发货）。 在实现方面，这只是将我们已经发出的声明源映射和 javascript 源映射结合起来的问题，但是我们还没有决定应该如何呈现这样的特性。 ts 代码中的Go to implementation已经对大多数代码具有有用的含义（这是去定义，但更喜欢实现/值声明）......我们是否以某种方式修改它（例如，如果我们解析为声明文件，尝试解析为一个 js 文件），或者我们添加一个新的端点？ 如果是后者，我们需要与 vscode 团队讨论我们希望如何将其浮出水面。

@DanielRosenwasser老实说，我们在这里真正需要的只是更详细地描述我们想要如何公开这样的事情——现在已经有了做这件事的工具。

vscode 团队的编码人员可以提出应该如何实现的想法，例如Go to js implementation或类似的东西，第一步是在 vscode 问题跟踪器上创建一个票证并交叉引用这个票证，以便交流开始。

我的理解是这里有几个相关的问题。 (1) 是最重要的，但我们也应该记住其他的：
1) 没有简单的方法可以导航到 TS 类型的 JS 或 TS 实现，如果该类型是在绝对类型包中声明的。 （或 .d.ts 不与实现共存的其他情况）
2) Go To Type Definition doesn't work when the selection is itself a type. 您将收到“未找到类型定义”错误。
3) Go To Definition 对非类型标识符的行为不一致。 有时它会导航到实现，有时则不会。 理论上这与 (1) 相同，但也可以在解决 (1) 的同时保留这种不一致。

我认为用户解决所有三个问题会更简单_不_添加第三个“转到”菜单选项。 相反，我的建议是只保留两个菜单项，但使它们的行为更加一致：

• Go To Definition 应该始终导航到 implementation ，无论它是本地代码、带有集成 .d.ts 文件的 node_modules 包，还是与 JS 包分离的绝对类型定义。
• 转到类型定义应始终导航到 TS 声明，无论选择是类型还是非类型标识符。

是否有其他常见的 TS 用例需要第三种选择？

顺便说一句，如果我们想让区别更清晰，我想我们可以将“转到定义”重命名为“转到实现”，但恕我直言，这似乎是一个可选的更改。 一致性（无论名称如何）是高位。

如果该类型是在绝对类型包中声明的，则没有简单的方法可以导航到 TS 类型的 JS 或 TS 实现。 （或 .d.ts 不与实现共存的其他情况）

_从技术上讲_如果您想手动旋转一些源映射以与 DT 包一起使用，它可能已经可以解决了。 但是这里绝对没有自动化的解决方案。 我们拥有的任何解决方案都是基于改进涉及 TS 编译器输出的场景，在这些场景中，我们可以输出在文件之间进行正确关联所需的额外元数据。 我相信今天有些软件包支持这一点 - 前几天我正在使用 azure js sdk 并调试一些东西，当我查看一些定义并发现它们在原始源中时感到惊喜。 所以是的，它适用于捆绑了最新--declarationMaps输出的 TS 源。

Go To Type Definition doesn't work when the selection is itself a type. 您将收到“未找到类型定义”错误。

我认为你们都应该在那个问题上开一个新问题。 这只是期望/错误的失败，imo。 至少，可以将错误做得更好——比如“选择只是一种类型，因此没有与其值相关的类型定义”。

非类型标识符的 Go To Definition 行为不一致。 有时它会导航到实现，有时则不会。 理论上这与 (1) 相同，但也可以在解决 (1) 的同时保留这种不一致。

它转到 _first_ 定义，其中 first 是相当随意的，并且基于诸如加载的订单文件之类的内容。无可否认， peek窗口更有用，因为它显示了所有定义站点。 “实施”没有发挥作用。

作为用户，如果它像这样工作，我会很满意：

Ctrl+单击符号（我通常只使用它来导航代码）当前会带来实现（如果它在 VS Code 中正在编辑的包内）或声明（如果它是来自依赖项的包） . 第一个不需要考虑。 第二，当它转到声明时，我想按 Ctrl+单击声明，它会将我导航到实现，如果它可以为我找到、下载并打开它。 否则，它会显示一条消息是什么问题阻止了找到/打开源。 如果它像这样工作，那就太棒了。

我认为定位原始源代码有以下场景：

1. 一个包是用打字稿和外部存储库中的原始源代码编写的，或者
   a) 发行版包括d.ts和js文件或
   b) 发行版包括d.ts 、 js和ts文件
2. 一个包是用当前存储库中的打字稿和原始源代码编写的（mono repo case）和
   a) 发行版包括d.ts和js文件
3. 包是用 javascript 编写的，外部存储库中的原始源代码以及
   a) 发行版包括它自己的d.ts和js文件或
   a) 发行版仅包含js文件，并使用外部@types定义
4. 一个包是用 javascript 和当前存储库中的原始源代码编写的（mono repo case）和
   a) 发行版包括它自己的d.ts和js文件

1b) - 很少使用，我不喜欢这种方法，因为像 bundlephobia 和 npm 趋势这样的资源会报告巨大的包大小，在运行时实际上并不是很大，但人们根据这些资源判断大小。 因此，依靠维护者在发行版中包含ts文件不是一个好主意，但当然如果包含ts文件，情况就解决了。

1a) -（大多数？）常见的情况。 包应该如何声明（通过 package.json 或源映射？）编译时原始源所在的位置（如 microsoft pdb符号文件声明）或可以从哪里下载，例如 git+revision+小路。 VS 代码将导航到本地文件或git fetch将其导航到本地缓存并在从声明到实现的导航中打开它

2a) - 如果可以自动检测mono repo的情况（使用一些启发式），原来的Ctrl+Click导航可以直接打开实现。 如果不可能，回退到 1a) 就足够了

我不太关心 3，但如果 3a) 可以在第二个 Ctrl+Click 导航上打开 JS 实现，那就太好了。 在 3b) 的情况下， @types包应该声明它注释的 JS 包，因此 VS 代码可以使用此信息导航到外部包中的 JS 实现。

我更不关心 4，但它可能具有与 2a) 相同的行为 - 4a) 的回退是 3a)

希望能帮助到你。

1a) -（大多数？）常见的情况。

是的，这就是我所说的，我们现在拥有所有支持的工具。 我们可以结合.js.map和.d.ts.map文件来生成从.d.ts到.js的映射（没有中间的.ts ）。 但是，嗯。 真的，你更喜欢去声明文件，然后再交互去关联的js？ 你不想直接跳到js？

“真的，你更喜欢去声明文件，然后再交互去关联的js？你不想直接跳到js？”

在 1a) 的情况下，双跳或单跳对我来说都很好。 虽然单跳可以说是“更高效”，但双跳却得到了“提醒”用户第二跳是从“库消耗”角度跳到黑匣子的好处（即提醒源导航到的文件不是当前项目的一部分）。 也许这种行为可以配置。

在 3a)、3b) 或 4 的情况下，我当然要双跳。 我首先想查看声明，然后才查看实现（在极少数情况下，例如调试）。 直接跳转到 JS 跳过 TS 声明会消除声明的所有好处。 所以，我绝对想先看看 TS 声明。

（结合多个帖子对@weswigham和@avkonst 的回复）

它转到第一个定义，其中 first 是非常随意的，并且基于诸如订单文件加载之类的内容。

在最常见的情况下，您要查看特定导入符号的实现，为什么会有多个定义？ 这是普遍情况吗？

生成从 .d.ts 到 .js 的映射（没有中间的 .ts）。

不确定我是否理解“没有中间 TS”。 您的意思是即使原始 .ts 源可用，VSCode 也会导航到转译的 .js 吗？ 这似乎是个坏主意。 如果原始源可用，那么 VSCode 应该导航到那里——就像调试器步入具有源映射的转译代码时一样。 也就是说，如果包作者是邪恶的或懒惰的，并且没有在他们的 npm 发行版中包含原始 TS 源，那么 VSCode 回退到转译的 JS 似乎是合理的，并且可能会显示一条警告消息，解释用户为什么看到这种奇怪的、不可读的代码并鼓励用户唠叨包作者在他们的包中包含原始源代码。

真的，你更喜欢去声明文件，然后再交互去关联的js？ 你不想直接跳到js？

我认为两步走不会增加价值。 我认为拥有独特、一致的用户体验要好得多：使用“转到类型定义”导航到类型定义，并使用转到定义（或转到实现——无论我们选择如何称呼它）转到原始类型源代码，或者，如果原始源不可用，则按上述方式转换为转译的 JS。

恕我直言，根据所选符号是在您自己的代码中还是在 node_modules 中定义，具有不同的行为会更令人困惑。 应该没关系。 如果我想看类型，VSCode应该带我去看类型。 如果我想看实现代码，VSCode 应该带我去那里。 尤其如此，因为在大型组织中，什么是“我的代码”和什么是“库代码”并不总是清晰的界线。 如果其他人将代码重构为共享的内部包，我就不必更改导航到该代码的方式。

我首先想查看声明，然后才查看实现（在极少数情况下，例如调试）。

似乎要求开发人员明确选择（通过选择一个或另一个菜单项）他们想要查看类型声明还是查看实现代码更清晰。 根据代码的来源使导航不一致似乎不必要地令人困惑。

> Go To Type Definition doesn't work when the selection is itself a type.
我认为你们都应该在那个问题上开一个新问题。 这只是期望/错误的失败，imo。

是的，这绝对可以先修复。 我将它包含在此处是因为如果采用我的首选解决方案（“转到定义始终导航到实现”），那么用户将养成在想要查看 .d.ts 时使用转到类型定义的习惯，因此它如果对类型执行此操作与它对非类型标识符的行为方式不一致，那会很奇怪。

“它转到第一个定义，其中 first 是非常随意的，并且基于诸如订单文件加载之类的东西。”

我在回复中没有提到它应该导航到第一个定义。 我说在 Ctrl+单击符号时，它应该首先进入定义（因为它现在有效），然后仅在随后的 Ctrl+单击 中进入实现。

“似乎要求开发人员明确选择（通过选择一个或另一个菜单项）他们想要查看类型声明还是查看实现代码更清晰。”

单独的上下文菜单很好，是个好主意。 它们与 Ctrl+Click 行为并不相互排斥。

想知道为什么还没有解决这个严重的错误。 随着打字稿采用率的提高，它变得越来越痛苦。

我不想听技术解释，我想知道为什么在对不同用户进行了如此多的描述之后，这个问题甚至没有得到承认。

@zjaml你想让它转到 TypeScript 源文件还是 JavaScript 源文件？ 支持 TypeScript 源文件。 这个问题目前仍然是针对 JavaScript 源文件的。

切线相关； 我有一个发布到 npm 的通用包的 monorepo。 由于这个公共接口，dist 是 js + d.ts 文件。 当我在 repo 中工作时，VSCode 总是跳转到 d.ts 而不是源。 你知道解决这个问题的方法吗？

@0x80我相信对于您刚刚描述的场景，这个问题仍然存在。 我认为你可以解决这个问题的唯一方法是，如果项目是开源的，并且你是从 typescript 源代码编译的。 然后你可以打开打字稿编译器的 --declarationMaps 标志，支持声明映射的 IDE 将转到打字稿源而不是 d.ts 文件。

这真的很关键。 我想要简单的事情：CTLR+单击并导航到 node_modules/library/source.js 或 source.ts 文件。 具有 60 个 node_modules 依赖项的开源项目，您又可以使用带资源管理器的记事本了。

当我右键单击一个组件时，我看到：“转到定义”和“转到类型定义”。 我想“太好了，这设计得很好，我的问题的解决方案就在这里！”。 然后我点击“Go to Definition”，然后...进入Type Definition。

这真的很关键。 我想要简单的事情：CTLR+单击并导航到 node_modules/library/source.js 或 source.ts 文件。 具有 60 个 node_modules 依赖项的开源项目，您又可以使用带资源管理器的记事本了。

+1
一样的需要。

恕我直言，没有实施的事实令人难以置信。 这样一个基本的，比较容易上手
构建可以为人们节省大量时间的功能。

恕我直言，没有实施的事实令人难以置信。 这样一个基本的，比较容易上手
构建可以为人们节省大量时间的功能。

+1

好吧，与此同时，当此功能尚不可用时，除了搜索整个 node_modules 之外，还有什么更好的解决方法吗？ 真的很不方便...
例如，当我想要的实际上位于node_modules/@com.abc/sample/src/core/internal/abc.ts时，我转到定义并引导我到node_modules/@com.abc/sample/lib/core/internal/abc.d.ts node_modules/@com.abc/sample/src/core/internal/abc.ts

@Happin3ss

除了搜索整个 node_modules 之外，还有更好的解决方法吗？

当前的解决方案 AFAIK 是声明映射。 这些是将 .d.ts 文件映射到相应 TS 源的源映射。 如果您可以说服您依赖的库实现声明映射（我认为这实际上需要在库包中发布 .d.ts 而不是依赖 @types），那么您将能够自动从您的客户端代码跳转到原始 TS（甚至 JS，如果在 JS 上使用 TS 编译器？）源代码。

我一直在做的是逐渐针对我最重要的依赖项（至少是那些在 TS 中编写的依赖项）提交 PR，让他们添加声明映射。

显然，如果不需要更改库会更好。

另一种解决方法（如果无法更改库）适用于库将 .d.ts 捆绑在包内但没有声明映射的情况。 在这种情况下，我将使用 Go To Definition 进入类型声明，然后单击 VSCode 中的 Explorer 按钮以显示文件夹侧边栏。 这通常让我非常接近包的src文件夹，因此不必搜索所有 node_modules，我只需浏览到正确的文件夹并打开正确的文件即可。 这取决于明确的文件命名等，并不是万能的。

只是为了 100% 清楚——我很想看到一个更好的图书馆解决方案，尤其是。 .d.ts 与包分开编写的那些。

不确定我是否错过了它，但它对于理解源、声明和声明映射的实际最小示例发生了什么非常有用。 我从来没有见过 Go to Definition、Go to Type Definition 或 Go to Implementations 实际上除了用于转译 TS 的.d.ts文件之外的任何东西。 我只是试图做一个简单的例子，但它不起作用； 我无法让 VS Code 转到.d.ts文件之外的任何内容，即使.d.ts.map就在它旁边。 我还发现有同样问题的其他人被忽略了。

支持像@types这样的外部类型很困难是可以理解的，但是即使是“快乐的道路”也无法工作是什么意思？

有许多库生成声明文件但不生成声明映射，并且不清楚启用它们的参数是什么。 添加此选项时没有明确说明，至少我可以找到一个。

是的，我确认声明映射没有解决问题。 我的项目有声明映射，但 vscode 无法导航到 .d.ts 文件之外。

如果发生这种情况肯定会很棒。

如果 ms vscode 开发人员有问题的“房间里的大象”，就是这样。

这个有更新吗？
我刚刚决定迈出一大步：从 JS 转向 TS。 我想——“我做错了什么？” 但实际上，这是 VSCode 的意外行为

这个有更新吗？
我刚刚决定迈出一大步：从 JS 转向 TS。 我想——“我做错了什么？” 但实际上，这是 VSCode 的意外行为

自从提出这种行为以来，历史悠久。 好吧，这里什么也没有发生。 目前没有计划。
对我来说，我一直使用 vscode 作为一种编辑器，而 Intellij 产品 (IDEA) 用于我的编码内容，即使我不太喜欢它。

开业5年，希望2025年修好

我在 #39426 中创建了失败的测试，但我不知道如何实现它

来自 ts dev 的另一个悲惨评论每天都在地狱中寻找定义

这太疯狂了......我以为我只是一个 TS 菜鸟，但现在我发现我得到的行为实际上是“标准的”？？？？ 太令人沮丧了，我使用过的所有其他 IDE/语言都在初始版本中实现了这个...... :( 我喜欢 VS 代码，但老实说这可能是一个交易破坏者

谁能解释为什么 VSCode 中带有 Python 扩展的go to definition/implementation功能，嗯，Python 语言比具有本机内置解决方案的 JS 更有效（至少它有效）？

那么发生了什么？
我将 scss.d.ts 用于 css 模块并且无法跳转到 scss。

同样在创建简单的 .js 和相应的 d.ts 时，我不能直接跳转到 js

为什么不使用webstorm？
可以解决这个问题！！！
我的版本 2020.1

为什么不使用webstorm？
可以解决这个问题！！！
我的版本 2020.1

因为它不是开源解决方案，也不是免费的

请解决这个问题。

很明显，这个问题只有在微软的一些经理接手的情况下才能解决，这个问题必须被管理和协调，一个经理开发一个工作流并将工作分配给编码员。 ☝
这个问题必须发送给管理层接管，他们决定如何实施。
因此，如果这里有来自 Microsoft 的主管人员，他可以试一试。 😊