Enable Go to Implementation in Typescript Editors

[doliver3]

Could you provide a way for Typescript Editors to list the implementations of a type? This would definitely help developer productivity to be able to find implementations of types faster.

For example, in the Atom Editor atom-typescript plugin you can press F12 to 'Go to Declaration' which as currently implemented you often arrive at the typescript .d.ts file which has the function signature but not the actual implementation.

Since the Typescript parser often generates the d.ts files from the .ts implementation files. Could that association between the d.ts and .ts files be preserved (perhaps output with a typescript compiler option) so that Typescript editors could take developers to a list of the implementing classes or functions?

I opened a similar request for the Atom-typescript editor, but they indicate that they cannot implement this without Typescript parser support: TypeStrong/atom-typescript#790

[DanielRosenwasser]

So you want this functionality to jump to the corresponding .js if available, provided that the definition is ambient, correct?

[DanielRosenwasser]

@RyanCavanaugh @mousetraps @bowdenk7

[doliver3]

So you want this functionality to jump to the corresponding .js if available, provided that the definition is ambient, correct? Yes this is a scenario that would be very useful for productivity. This alone would be very valuable. I believe the atom-typescript author believes more hooks in the Typescript compiler would make it easier for him to implement this. I'm unclear on whether this is information on js implementation line numbers is information the typescript compiler would typically know internally.

In addition, another scenario would be enabling a jump to the original typescript .ts file definition in the library being used by the application. I would imagine this information is available pre-compile to d.ts and .js files. We now have entire sets of libraries being written in .ts files as source outputting ES5 syntax js. It would be nice to achieve the ability to jump to the original typescript implementation definition in the .ts files.

I'm aware this is asking even more to jump to the .ts file implementation in the required library as it might need source map usage or distribution of source/link to original ts source. It would seem to me that the typescript compiler that generates the initial library of functions and classes would know the lines where the implementation is at and could preserve the line numbers when the library is distributed somehow so that the typscript compiler of the application using the class could know what line to jump to in the library.

Is this information on line number of implementing function/class available in source maps? Are there other sources of this information?

[DanielRosenwasser]

Given that we are going to be using the --allowJS flag, the language service should be able to work with the JS files.

I don't know how .d.ts files and .js files currently work together in that respect. @sheetalkamat probably (definitely) knows more about this than I do.

[riknoll]

Reopening, because going to js files isn't supported quite yet

[ubershmekel]

Any updates on this one? The current state of typescript is that you cannot jump to the implementation of code in many prominent libraries.

This issue has been moved/closed/duped/deduped multiple times and fixing this bug could be a huge productivity boost.

https://github.com/ubershmekel/vscode-ts-goto-source has a project that reproduces the issue. As explained in https://github.com/Microsoft/vscode/issues/26325 and referenced in https://github.com/Microsoft/vscode/issues/10806 and https://github.com/Microsoft/vscode/issues/18321

Note I had to use "typescript.disableAutomaticTypeAcquisition": true from one point to use the javascript "go to definition" because it seems the .d.ts files take over if found.

[mmc41]

@DanielRosenwasser Any updates on this? - Single most wanted feature for me.

[Pajn]

This is particularily annoying if working in a monorepo written entirely in Typescript. I have multiple times when adding a field to a type or similar smaller changes used "go to definition", added it and then later found it missing again realizing that I added it to the .d.ts file and not the actual .ts file

[ghost]

@DanielRosenwasser Is this progressing? I would really love this feature

[mrdulin]

same issue. Want to "Go to implementation" to the source code, not xx.d.ts

[bobmoff]

Yep, multiple times a day I by mistake edit the declaration file after using cmd+click and end up confused when the code doesn't run correctly. Especially since src and dec look very similar. Would be awesome if there was some way to choose if I want to go to source of declaration, or even better if VSCode would figure this out as going to source is always more preferable IMHO (if it is available).

[Pajn]

going to source is always more preferable IMHO (if it is available)

When the source is in TS. If the source is in JS though there's a good reason to go to the .d.ts

[d-akara]

When the source is in TS. If the source is in JS though there's a good reason to go to the .d.ts

Why? I can just hover to see the type definition. Anyway, there should be a separate command for type definition vs implementation.

[ivmos]

Is there any reason why this is still pending? A workaround, alternative or something? Thanks in advance

[weswigham]

Since the Typescript parser often generates the d.ts files from the .ts implementation files. Could that association between the d.ts and .ts files be preserved (perhaps output with a typescript compiler option) so that Typescript editors could take developers to a list of the implementing classes or functions?

I have a branch of #21930 that enables producing precisely these declaration file sourcemaps (and will have that out for review either on request or once #21930 is merged), and am working on adding support into our LS for following these maps. We want to ship it in 2.8.

So yeah, we've been working on it. It just needed a lot of internal changes. 😄

[zheeeng]

Expect updates on this issue to relieve the pain on finding implementations through manually expand folders under node_modules and locate the entry module file.

[derN3rd]

Is there any workaround for this? As we have a big module for our db queries written in ts it would be really nice to see the real source code with one command instead of searching through the node_modules.

[ewnd9]

@derN3rd There is vscode-search-node-modules extension to browse node_modules in the command panel (and I also have a fork which always opens README vscode-open-node-modules)

I understand it's far from the perfect ux to click on require/import and open source a file, but definitely better than scrolling node_modules

[weswigham]

@derN3rd we will be shipping a --declaratrionMap flag in 2.9 (which may be released during next month), and we've already enabled going to definitions in the original source TS over an associated .d.ts using them (which, if you're shipping declaration files in your node modules folder may get a lot of what you want). We're also looking into jumping to/from the associated JS as well, provided normal sourcemaps are also on.

[derN3rd]

@weswigham thanks for the fast reply! Sounds good Could you post an update here if the feature is ready or ready to be tested?

[weswigham]

--declarationMap (and associated LS redirection) has been in our nightlies since just after the 2.8 release. The only bit we've not done yet is the JS file hopping, as that may require some extra editor coordination.

[derN3rd]

Any news for that on 3.0-rc?

[SheikhG1900]

Same issue with .css and .json files. Go to Definition taking me to .d.ts file.

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'

Go to Definition on ./App.css takes me to

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;
}

[carpet92]

VS Code now ships with TypeScript 3.0.3. Any news on this issue?

[robsman]

Works for me (declaration maps generated with TS 2.9.2, running VSCode 1.27.0). Navigating from an API consumer (implemented in JS) Go to Definition takes me to the implementation in the .ts file.

[derN3rd]

@robsman Go to Definition should take you to the compiled js code, while Go to Type Definition should take you to the .d.ts file.

How do you use/include your compiled module, to open the source files?

That issue still exists for me in VSCode 1.27.0, as both functions take me to the .d.ts file

EDIT: I think I misunderstood your comment. Does it take you to the real code? If so, are you using a monorepo or is your compiled code shipped in a own npm module? Do you ship the source files with your compiled code?

[robsman]

@derN3rd re-tested, both Go to Definition and Go to Type Definition as well as Peek Definition take me to the real code in the .ts file.

The API declaration and implementation both sit in a separate module that the calling package refers to as a git+ssh... dependency.

[carpet92]

@robsman I think Go to Definition should refer me to source of "this" class or function in source js file (if it's javascript) inside node_modules not .d.ts. Like it works in Sublime Text 3 I mean. Anyway I don't understand for what VSCode this feature in the current state

[prufeng]

Hope can prioritize this issue, it is really a big pain, from so many comments and related issues.

[bartlettpsj]

Please add me to the long list of folk trying to use command-click to navigate through the code. I have no TS in my project and the npm package I am navigating to does not use TS, yet command-click on require('co-body') takes me to an internally generated TS definition. I am long time IntelliJ user and still, because of this, I fall back to IntelliJ.

[chaosforfun]

it's a long request

[restjohn]

I like VS Code a lot and I just started a new Node project and decided to use TypeScript for the first time. So far so mostly good, but this issue has been a pain point. Working in open-source, the ability to click through to real source code in dependencies is vital to work-flow. I am working in TypeScript source files and using JS NPM modules with associated @types/xxx modules that have no associated documentation. IntelliSense with TypeScript is great, but doesn't always provide enough information. At the very least, being able to click straight through to the module source from the import statement would be nice. I believe on some libraries that works, and on others, e.g. Passport, I can't get past the adjunct TypeScript stubs in the @types module.

[remcohaszing]

This should be labeled Bug, not Suggestion.

The lack of code navigation really ruins the VSCode experience for JavaScript developers.

[phil-lgr]

sorry to spam the thread but @promaty I use the search-node-modules extension 😬 for now

[joeysino]

WebStorm has the same behaviour: StackOverflow, BugTracker

• VSCode has "Go to Definition" and "Go to Type Definition" actions

• WebStorm has "Go To Declaration" and "Go To Type Declaration" actions

But when using TypeScript, both IDEs do the same thing: always go to the type definition!

[henrahmagix]

"Go to Definition" and "Go to Type Definition", when used on node_modules/ libraries, both take me to .d.ts files. I'm on the latest VS Code as of writing (1.34.0).

For example: npm package @angular/core@7.2.15, when I import TestBed from @angular/core/testing and try to see the definition of TestBed.createComponent, I get two different things:

• "Go to Definition" -> node_modules/@angular/core/testing/src/test_bed_common.d.ts line 117
• "Go to Type Definition" -> node_modules/@angular/core/testing/src/component_fixture.d.ts line 14

This basically means that the Angular source code is hidden from me in VS Code 😞 I'm not sure if that's a symptom of how the Angular library is written, or how TypeScript/VS Code finds source implementations.

All I know is I can only reliably use "Go to Definition" and "Go to Type Definition" on my own code, in which case I get taken directly to the source; I'm never shown a .d.ts file for my own code.

[silverqx]

We have to manually search source codes for now :/

[trungklam]

Aw, I just figure out that somehow Intellij IDEA have this function work really well, even I'm on the same project, using Typescript 3.0.1

[kaelzhang]

I thought the priority of this issue should be bumped up.

We have to command + , to open the workspace settings -> uncheck Use Ignore Files -> delete Search: Exclude: **/node_modules, and manually search source codes.

EVERY DAY!

[hushicai]

So that's why flow is still useful.

[sheerun]

Could someone from typescript team suggest where in code this can be potentially fixed?

[sheerun]

A funny thing is that if some package doesn't have types available "Go To Type Definition" actually works better for it. It means that not using typings is better if you like "Go To" features 😄

Here's screencast that shows that I'm able to go to definition of device packages that doesn't have typings, but compression leads me to some random typings file:

https://giphy.com/gifs/j3VCp0LVKr5LsMUh11

@RyanCavanaugh I must agree with other people, this should be labeled as bug, not suggestion..

[tafelito]

in my case, if I have something like this defined in my own code

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

if the T comes from a npm module, when I try to go to definition, it will show me 2 definitions. My own code and the typing definition. If I go to type definition it goes straight to the definition file. In the first case, it should go straight to the definition. To work around this, I changed the editor --> goto location: multiple to goto instead of peek

[yurylavrukhin]

I need this feature. How can I help with its implementation?

[rjmacarthy]

+1 for this please!

[nathanredblur]

since 2015 and no solutions :(

[weswigham]

The OP was asking if we could go to .ts files when we find .d.ts files - if you ship the .ts files with the .d.ts files and the declaration maps generated by --declarationMaps, that is our current behavior (so that's pretty done). The second request in this thread, which is what we now track here, is an option to go to the output .js file (which could be useful if, for example, the .ts sources aren't shipped). Implementation-wise, that's just a matter of combining the declaration source maps and javascript source maps we already emit, however what we haven't decided on is how such a feature should be surfaced. Go to implementation in ts code already has a useful meaning for most code (which is go to definition, but prefer implementation/value declarations)... do we amend that in some way (say, if we resolve to a declaration file, try to resolve to a js file instead), or do we add a new endpoint? If the later, we need to talk about how we want to surface it with the vscode team.

@DanielRosenwasser honestly, what we really need here is just a more fleshed out description of exactly how we wanna expose a thing like this - the tools to do it are now in place.

[silverqx]

Coders from vscode team can propose ideas on how this should be implemented, eg Go to js implementation or something like that, a first good step would be to create a ticket on vscode issue tracker and cross-reference this tickets so that communication can begin.

[justingrant]

My understanding is that there are several related problems here. (1) is the big one, but we should keep the others in mind too: 1) There's no easy way to navigate to the JS or TS implementation of a TS type if that type is declared in a DefinitelyTyped package. (or other cases where .d.ts isn't colocated with the implementation) 2) Go To Type Definition doesn't work when the selection is itself a type. You'll get a "no type definition found" error. 3) Go To Definition on a non-type identifier behaves inconsistently. Sometimes it will navigate to the implementation, sometimes it won't. In theory this is the same as (1), but it's also possible to solve (1) while leaving this inconsistency in place.

I think it would be simpler for users to solve all three problems without adding a third "Go To" menu option. Instead, my suggestion would be to retain only two menu items but make them behave more consistently:

• Go To Definition should always navigate to the implementation, regardless of whether it's local code, a node_modules package with integrated .d.ts files, or a DefinitelyTyped definition that's separate from the JS package.
• Go To Type Definition should always navigate to the TS declaration, regardless of whether the selection is a type or a non-type identifier.

Are there other common TS use-cases that require a third choice?

BTW, I guess we could rename "Go To Definition" to "Go To Implementation" if we wanted to make the distinction clearer, but IMHO this seems like an optional change. Consistency (regardless of the name) is the high-order bit.

[weswigham]

There's no easy way to navigate to the JS or TS implementation of a TS type if that type is declared in a DefinitelyTyped package. (or other cases where .d.ts isn't colocated with the implementation)

Technically if you wanted to hand spin some sourcemaps to go with a DT package, it could kinda work out already. But there's definitely no automated solution here. Any solution we do have is based on improving scenarios involving TS compiler output, at those are the only times when we can otuput the additional metadata required to make the correct associations between files. Some packages support this today, I believe - I was using the azure js sdk the other day and debugging some stuff, and was pleasantly surprised when I went to some definitions and discovered they were in the original source. So yeah, it works with TS sources that have up-to-date --declarationMaps output bundled with them.

Go To Type Definition doesn't work when the selection is itself a type. You'll get a "no type definition found" error.

I think y'all should open a new issue on that one. That's just a failure of exepections/bug, imo. Minimally, the error could be made better - something like "selection is only a type and so has no type definition associated with its value".

Go To Definition on a non-type identifier behaves inconsistently. Sometimes it will navigate to the implementation, sometimes it won't. In theory this is the same as (1), but it's also possible to solve (1) while leaving this inconsistency in place.

It goes to the first definition, where first is pretty arbitrary, and based on things like the order files were loaded in. The peek window is admittedly more useful, since it shows all definition sites. "Implementations" don't come into play.