Go to definition not working as expected when typescript definitions are included

[politician]

• VSCode Version: 1.46.1
• OS Version: macOS Catalina
• Does this issue occur when all extensions are disabled?: Yes

TLDR; When writing a Typescript package to be consumed by both Javascript and Typescript, "Go to definition" works for one or the other but not for both.

Problem 1

Steps to Reproduce

1. Given a NPM package that contains type declarations (.d.ts) and no sourcemaps.
2. When working in a Typescript or a Javascript project importing this package, if I ⌘+click, I am taken to the type declaration. However, I would expect to be taken to the source file and would expect to be taken to type declarations file if I click "Go to type definition".

Current solutions

• If the module is written in Javascript: Add sourcemaps.
• If the module is written in Typescript:
  • Removing type declarations from the package solves the issue for Javascript projects but it means the package is no more compatible with Typescript projects! So this is not a viable solution.
  • Adding sourcemaps along with Typescript sources, leads to Problem 2 below.

Problem 2

Steps to Reproduce

1. Given a NPM package that contains its Typescript source, compiled Javascript, type declarations and sourcemaps.
2. When working with a Typescript project that imports this package, if I ⌘+click, I am taken to the source file in Typescript. All is good as expected.
3. When working with a Javascript project that imports this package, if I ⌘+click, I am still taken to the Typescript source file. However, this is not an expected behavior as I am coding in Javascript, so if I want to debug the code, I'd be lost and have to learn Typescript and setup a Typescript compiler.
   The expected behavior should be to take me to the compiled Javascript (which is what I am actually importing in my project).

Currently, there is no way to control this behaviour, because VS Code probably uses the same algorithm to detect type declarations for Javascript and Typescript.

Possible solutions

1. VS Code's responsibility: Detect if the project is Javascript and if the source file being taken to is Typescript, then ignore typings. This has the advantage of requiring zero configuration.
2. Package publisher's responsibility: Introduce a typescript entry in package.json to include type declarations (and maps) to be used only for Typescript. This has the advantage of letting the package publisher decide what they want to do instead of the consumer.
3. Package consumer's responsibility: Do not pick up type declarations if they are specifically excluded in jsconfig.json

   {
     "exclude": ["./node_modules/npm-package/types"]
   }
   

4. Package consumer's responsibility: Introduce a new jsconfig.json entry useTypeDeclarations that can be set to false.

Current alternative solution for Problem 1 & 2

1. The package publisher shall create two subfolders, one for type declarations and one for the compiled Javascript code
2. The package consumer must import directly the subfolder containing the code instead of the generic package name

package.json

...
"name": "npm-package",
"types": "types/index.d.ts",
"main": "js/index.js",

Project code

import { x, y, z } from "npm-package/js";

This solution has a few downsides that I am aware of:

• This is not a common way of consuming NPM packages
• In the case of hybrid packages that supports several module types (CommonJS, ES6, etc.), it means the consumer has to choose which one to use while many tools (Webpack, Rollup, Parcel, ...) would have made the decision for him.

Related discussions

• Publish sources and source maps to npm googleapis/google-cloud-node#2867

[yume-chan]

Duplicate of microsoft/vscode#68782, microsoft/vscode#82054

See microsoft/vscode#82054 (comment)

[politician]

@yume-chan Both of these "duplicates" didn't come with any solution. These comments are talking about the problem but nobody reacted.

• cmd+click skip typescript definition and go to source? vscode#68782 (comment)
• Go to definition sometimes jumps to non JavaScript file vscode#82054 (comment)

This is a real problem, please read my initial post: as a package publisher, there is NO WAY for me to publish a package where "go to definition" will work correctly for both JS and TS. And there are some solutions that I proposed in my initial post.

[politician]

@mjbvz This is not a Typescript issue, this is a VS Code issue as far as I am aware
Typescript definitions/sourcemaps work perfectly. The issue is that VS Code is using them for Javascript

[RyanCavanaugh]

@Incorrupt VS Code asks TS where to go in both cases; I believe the bug is on our end

[politician]

@RyanCavanaugh

• is VS Code asking TS where to look for the type declarations + source maps?
• is VS Code passing the context of the project (wether the user is using TS or not)?

If both are true, then I can see how this is TS responsibility.
And in this case I can only think of a solution that involves generating two sourcemaps: one for JS projects pointing to the compiled code, one for TS projects pointing to the source code.

What do you have in your mind?

[betaorbust]

I've been running into this more and more as I work with mixed TS/JS projects.
Is there a path forward to addressing it at the TS level, or should we be asking VSCode for support there?

Thanks!

[pluveto]

It is very unreasonable to show only the interface rather than the implementation, because in many cases we want to know the details of the functions we used

[hopper01]

I've been running into this more and more as I work with mixed TS/JS projects. Is there a path forward to addressing it at the TS level, or should we be asking VSCode for support there?

Thanks!

+1

[PabloLION]

@hopper01 please don't write a post with only "+1" . just add a reaction with the smiley face.
@politician I am facing the same problem and it slows me by a lot. As you mentioned, there's a bunch of "duplicates" and not yet really resolved. They are closed(assumably) because a team member offered a solution and the author didn't reply. In this way the last comment looks like an answer, like in these ones:

• cmd+click skip typescript definition and go to source? vscode#68782
• With multiple definitions "Go to definition" shows peek definition popup instead of going to definition vscode#70032

But I'm not clear why this one is closed too:

• Go to definition not working for JavaScript vscode#70992

We are trying to make VScode better and it's not totally open source(with not-FLOSS). We are like unpaid workers here. Please treat us better. Ignoring is worse than rudeness for me. (By the way contributing to https://vscodium.com/ is an alternative method to push VScode)

Since this issue is still open (although under Typescript repo), I'll add my opinion here.

With vscode(v1.61.2), there are more than five related options in the right click menu:

1. Go to Definition
2. Go to Type Definition
3. Go to Implementations
4. Go to References
5. Peek ... (A sub menu)

And none of these can really go to the corresponding JS file, where the class is really defined.

The UI logic shown here is that we can jump to TS declaration file (.d.ts) with "2. Go to Type Definition" and to JS file with "1. Go to Definition". But in fact they just both goto .d.ts.

Then the "3. Go to Implementations" does show a list to peek, although all items in the list are *.d.ts.

I'll keep an eye on this issue until we see a solid answer.

[andrewbranch]

Late to the party here, but isn’t this a duplicate of #6209?

[PabloLION]

@andrewbranch I just checked #6209 and I think its basically the same. I can see some new issue coming up once in a while but it seems no one is fixing it. One thing I didn't understand thoroughly is why the repo in vscode redirect us to the Typescript repo. I thought it's more about the vscode functionality, not the language. Is there anything you did blocking the functionality?

[andrewbranch]

All JS intelligence in VS Code comes from the TypeScript compiler.

[andrewbranch]

Redirecting this to #6209. The discussion there is active.

[PabloLION]

@andrewbranch Thank you! I'm very happy that someone in the team can notice this problem.