I'm happy to see continued enthusiasm for solving this problem. Keep the upvotes and (especially) constructive suggestions and PRs coming! Like many hard things, eventually I'm sure we'll help to get a solution built for this annoying gap in the TS developer experience.

[BLOCK QUOTE].

As far as I can tell, this impression is not correct. Almost all* packages that are written in TS, transpiled to JS, and published to npm don't work with "Go To Implementation" any more than packages originally written in JS.

I said "almost all" above because there is a way to make it work: using the [declarationMap]([URL] tsconfig compiler option. But:

1. This setting is not enabled by default. IMHO it should be enabled by default whenever `sourceMap` is enabled. (Maybe also when `inlineSourceMap` is enabled?)
2. There is AFAICT no evangelism from the TS team (or anyone else!) about how package authors should enable this setting and include declaration map files when publishing their packages to npm.
3. There's also no push to get declaration map files into existing DefinitelyTyped packages. Could this be automated instead of relying on 1000s of type-package maintainers to do it?

Anyone who wants to see this problem get better could:

1. **Send a PR to try to change the default of `declarationMap` to be `true` if the `sourceMap` or `inlineSourceMap` option is `true`**. This minor change would probably have the biggest impact on this problem over time.

2. **Send a PR to update the TS docs to be more vehement that `declarationMap` should be enabled for all library packages**, and explaining why ("_because "Go To Implementation" in VS Code relies on declaration map files_"). These documentation changes will be crucial if (1) is not approved.

3. **Send a PR that adds or extends the TS docs with specific guidance for package authors**, including "publish your sourcemaps" and "publish declaration maps".

4. **Write a tool that will automatically add declaration map files to all compatible DefinitelyTyped packages**, and convince the DefinitelyTyped maintainers to merge the output of that tool into every compatible DefinitelyTyped package. Part of the work would be figuring out what "compatible" means and what packages' declaration maps can't be automated. Note that [USER] above was pessimistic that this automation would be possible. But I wonder if things have improved since then to make automation possible? Or if it'd be possible for a large subset of packages? Here's what he said:

[BLOCK QUOTE].


5. **Send a PR to change the build actions for DefinitelyTyped to warn users if they try to add a new package that lacks a declaration map**. Not sure if this is something that can be done outside the DT maintainer team, depending on how the existing DT toolchain works. Someone who knows DT better than me could answer this.

The community has agency! If we want things to get better, any of the items above can make things better.

There's also IMHO another confusion with "Go to Definition" vs. "Go To Type Definition" are implemented. My preference would be for "Go to Type Definition" to navigate to the types and "Go to Definition" to navigate to the implementation. Not sure this is worth changing community expectations, though, given how long the current behavior has been in place. For more details, see: [URL]