Repository navigation
Go To Source Definition feedback thread #49003
Description
Activity
I was surprised that this didn't work as cleanly with a
module.exports = someFunc, like inleft-pad.// index.mts import leftPad = require("left-pad"); leftPad("", 4);
// tsconfig.json { "compilerOptions": { "module": "node16", "strict": true, "outDir": "./out", } }
Screenshot
Reacted by Andrew BranchFound a crash in an inferred JS project when using a destructured declaration on a
require.// index.js const { ncp } = require("ncp");
// package.json { "name": "yadda", "version": "1.0.0", "description": "Yadda", "main": "index.js", "dependencies": { "ncp": "^2.0.0" } }
TSServer Crash
<semantic> Response received: findSourceDefinition (625). Request took 3 ms. Success: false . Message: Error processing request. Debug Failure. Illegal value: SyntaxKind: BindingElement Error: Debug Failure. Illegal value: SyntaxKind: BindingElement at Object.tryGetModuleSpecifierFromDeclaration (ms-vscode.vscode-typescript-next-4.8.20220524/node_modules/typescript/lib/tsserver.js:16587:26) at Object.getDefinitionAtPosition (ms-vscode.vscode-typescript-next-4.8.20220524/node_modules/typescript/lib/tsserver.js:139272:63) at Object.getDefinitionAtPosition (ms-vscode.vscode-typescript-next-4.8.20220524/node_modules/typescript/lib/tsserver.js:164900:38) at IpcIOSession.Session.findSourceDefinition (ms-vscode.vscode-typescript-next-4.8.20220524/node_modules/typescript/lib/tsserver.js:176077:50) at Session.handlers.ts.Map.ts.getEntries._a.<computed> (ms-vscode.vscode-typescript-next-4.8.20220524/node_modules/typescript/lib/tsserver.js:175294:61) at ms-vscode.vscode-typescript-next-4.8.20220524/node_modules/typescript/lib/tsserver.js:177441:88 at IpcIOSession.Session.executeWithRequestId (ms-vscode.vscode-typescript-next-4.8.20220524/node_modules/typescript/lib/tsserver.js:177432:28) at IpcIOSession.Session.executeCommand (ms-vscode.vscode-typescript-next-4.8.20220524/node_modules/typescript/lib/tsserver.js:177441:33) at IpcIOSession.Session.onMessage (ms-vscode.vscode-typescript-next-4.8.20220524/node_modules/typescript/lib/tsserver.js:177467:35) at process.<anonymous> (ms-vscode.vscode-typescript-next-4.8.20220524/node_modules/typescript/lib/tsserver.js:180102:31) at process.emit (node:events:390:28) at emit (node:internal/child_process:917:12) at processTicksAndRejections (node:internal/process/task_queues:84:21)Daniel Rosenwasser (@DanielRosenwasser) can you give me compiler options for that? Also, does go-to-def jump to your ATA cache?
inferred JS project
Oh, missed this.
But still can’t reproduce 🤔Was able to reverse engineer from the stack.- added a commit that references this issue
on Jun 3, 2022 would enabling
"declarationMap": truemean we need to include the original .ts files as well? I don't think many packages currently do this. But this does work with@types/typed packages? Is there any way to enable this for packages that ship their types but not the original .ts files?Reacted by ThaJaywould enabling
"declarationMap": truemean we need to include the original .ts files as well?Yes.
But this does work with
@types/typed packages? Is there any way to enable this for packages that ship their types but not the original .ts files?What is “this” in this context?
declarationMapmaps locations from.d.tsfiles to the.tsfile that created them. I don’t quite understand the question/suggestion for what you could do with this in the absence of the TS sources.And to be clear, declaration maps have always been used for Go To Definition when available—nothing new about that in 4.7. rxjs is an example in the wild—a plain old Go To Definition on anything you import from there will go to the TS source.
I was confused because the packages I was trying with "go to source definition" weren't working. I think this is because I had
"moduleResolution": "node16",in my tsconfig. Its fixed with typescript 4.7.3Reacted by Andrew BranchHey Andrew Branch (@andrewbranch) great work on this, I had a quick Q (you kind of mentioned it in your original comment).
Shouldn't "Go To Definition" be the default for this and there should be a separate command for going to the type definition? I only ask this because it will be inconsistent with other languages being used in VSCode where "Go To Definition" would go to the original source definition of that symbol. I feel like most people using the "Go To Definition" command are expecting it to go to the source code not the type, so I was surprised to see the solution was not to change it but instead add a new command.
This will end up making TS/JS a "special snowflake" in the VSCode UI where you need to navigate to another command to get the same result that you'd have from other languages. I could be wrong but that seems to go against VSCode's goal to have familiar UX across all languages
Reacted by Valentin Hăloiu, Max Chang, DejanIvanovic, AK, Remco Haszing, ThaJay, Brian McBarron, Zakhse, stephen304, Derek Shockey and 4 moreI think I answered that in this Twitter thread. Let me know if that leaves you with any more questions.
Ok thanks Andrew Branch (@andrewbranch) I understand this is not wanting to change/break workflow for those who are already used to it.
Reacted by ThaJayReacted by ThaJayWell there’s also the fact that Go To Type Definition means something completely different, and Go To Definition is kind of sacred in that it shows you with 100% confidence what the compiler thinks the definition of some code is. Keep in mind that Go To Definition does take you to the original, concrete source when it can do so with 100% confidence—that is, when declaration maps and original TS sources exist. It would be great if this were always true, but the reality is that TS is a bit of a special snowflake in that our “header files” and “implementation files,” if you want to extend the analogy to other languages, are often written, by hand, by different parties at different times under different versions installed to different locations and the extent to which they match each other is determined solely by the skill of the declaration author and the ability of the user to install matching versions of each (I’m referring to getting .d.ts files from DefinitelyTyped, of course). Such uncertainty deserves to be treated differently than the distinction between a header and implementation file compiled from a single source. And also/again, types are so central to the process of writing TypeScript that even if we could always take you to the right spot in the JS with 100% certainty, I still don’t think we’d call it the “definition” (at least for TS users).
Reacted by Ryan Cavanaugh, Jason Williams and SlurpTheoReacted by ThaJayWhen using this feature for an imported Typescript library (
AngularFirestore), in VSCode v1.68 and Typescript 4.5.5, I get 'No source definitions found'. I don't know why; my guess is that this feature requires Typescript 4.7.If my guess is right: could we have a better message please? Maybe 'Typescript 4.7 required in order to support Go To Source Definition'?
Or probably better: disable the feature until the environment can support it?
Reacted by ThaJay and Kyle Summersjzabinski-dolios VS Code does hide the menu item if it didn’t see TypeScript 4.7 in the workspace, and gives this error message if you invoke it by keyboard shortcut anyway:
Unless something really weird is happening, I would guess you’re actually using VS Code’s bundled version of TypeScript (now 4.7) in the workspace, and we really couldn’t find the source for that import due to one of the limitations described in the issue body.
Reacted by ThaJay24 remaining items
If it does something that surprises you, I would like to hear about it here, even though it might be a known limitation. Make sure to include:
- The code you triggered the request on
- The import statement importing the thing you tried to navigate to
- What result(s) were returned, if any (screenshot is ok for these top 3)
- What version of the library you tried to navigate to is in your node_modules (check its package.json)
- If you had a corresponding Types (@types) library in your node_modules, and what version it is
Reacted by starball and ThaJayWillem Vanhulle (@wvhulle) Have you read this topic? #49003 (comment)
Willem Vanhulle (@wvhulle) Have you read this topic? #49003 (comment)
I have issues with the libraries vite and sveltekit. Would this be because of the way they are packaged?
As of today’s VS Code Nightly, you can enable a setting that replaces Go To Definition with Go To Source Definition, allowing you to ctrl/⌘-click to trigger it. If source definitions cannot be retrieved, it falls back to Go To Definition. Since this addresses the only piece of feedback I’ve consistently received, I’m going to close this issue. Thanks everyone!
Reacted by jbarnat and Dante Flavian BenitezReacted by Remco Haszing, Brian McBarron, starball, Ben Wormald, Sam Spycher, Tim Perry, effectivetom, Seth Moon, Reza, Olivier Lacan and 4 moreAnother related Stack Overflow question: Go to implementation instead of TypeScript declaration (where I've edited my answer post to mention the new "Prefer Go To Source Definition" setting).
Andrew Branch (@andrewbranch) If possible, please also get microsoft/vscode#82054 temporarily reopened to mention this new setting and then close it again.
hi, i am new to typescript, and recently study vue-typescript-admin-template
i meet a issue, when disable typescript "Prefer go to source definition", cmd + click jump to Types (@types) node_modules'
index.d.tsfile, when i useGo to source definition, vsc hints me:No source definition found:
but when i enable
Prefer go to source definition, vsc go to js source definition exactlyReacted by Stanislav Ilnytskyi上二下中 (@toien) would you be able to file a new issue with specific repro steps? See the “Make sure to include” list at the very top of this issue. Thanks!
This is random, but does anyone know how to make a keyboard shortcut for this?
I can't get the "Prefer Go To Source Definition" to work for the
Typescript JSXlanguage mode:
I am a newbie with this level of customization, but any idea how to get it to show up here?
Different flavors of this get a little bit out of hand, I guess... but what I really miss (or I don't know how to achieve...) is being able to jump to the runtime source when the original source (or dts) is available.
I'm in a JS file and I have real problems when it comes to jumping straight to a sibling JS file (
./upload.js):const upload_1 = require("./upload"/*1*/);
No matter what I do here, I'm being brought to
upload.d.ts.- added a commit that references this issue
on Jun 6, 2024 As of today’s VS Code Nightly, you can enable a setting that replaces Go To Definition with Go To Source Definition, allowing you to ctrl/⌘-click to trigger it. If source definitions cannot be retrieved, it falls back to Go To Definition. Since this addresses the only piece of feedback I’ve consistently received, I’m going to close this issue. Thanks everyone!
using the vim plugin coc-tsserver when I navigate to useRef, the file is still minified and unreadable.
Screen.Recording.2024-07-31.at.1.41.18.PM.mov
Reacted by wu aoxiangFabrizio Bertoglio (@fabOnReact)
"Prefer Go To Source Definition" Does not work in JSX and TSX files, it always falls back to "Go To Definition"Reacted by EmpathyZeroedReacted by Angst- added a commit that references this issue
on Jun 13, 2025 - added a commit that references this issue
on Dec 30, 2025
Seeding a thread for feedback on / issues with Go To Source Definition (#48264) ahead of the 4.7 release.
TL;DR
TypeScript 4.7 (already in nightly) and VS Code 1.67 (already released) will contain a new navigation command called “Go To Source Definition” that attempts to find a definition in non-ambient TypeScript or JavaScript code. (Ambient code means
.d.tsfiles ordeclarecontexts inside regular TS files—in other words, definitions separated from concrete implementation.) The most common reason to use this is if you want to look at the JS implementation of something you imported fromnode_modules, where Go To Definition only jumps to.d.tsfiles.Our ability to find concrete definitions in JS when Go To Definition returns only
.d.tsfiles varies wildly based on a lot of complicated stuff. Sometimes this feature returns results that we can be nearly 100% confident in. Sometimes it returns a guess that definitely might be wrong. Sometimes it returns nothing. If it does something that surprises you, I would like to hear about it here, even though it might be a known limitation. Make sure to include:@typeslibrary in your node_modules, and what version it isKnown limitations
The main thing that makes this feature go from 100% confidence to guesses that could go wrong is JavaScript whose exports we can’t analyze, probably because they have some kind of UMD wrapper. When that happens, we try guesses. The quality/presence of guesses is impacted by:
@typespackage, if present, matches that of its JS counterpartimport { add } from "lodash"currently returns three results; two refer to the correct function, but one is a false positive (SetCache.prototype.add):Function parameters, and properties accessed on them, are unlikely to return any results, because definition information doesn’t tell us every caller of the function—we only know where the parameter itself is declared, and what type it expects. The values passed into it could come from anywhere, even if in practice they have a single definition provided by a library:
FAQ and Q that should be FA but aren’t
Can you please make this the default / give me an option to make this the default for Go To Definition / ⌘-click?
Not right now, but comment / 👍 an existing relevant comment if you feel strongly about this and tell me a bit about why.
Can I make a keyboard shortcut for this?
Yes. Command palette → Preferences: Open Keyboard Shortcuts (JSON)
{ "key": "cmd+shift+F12", "command": "typescript.goToSourceDefinition", "when": "editorTextFocus" }What’s the difference between this and Go To Implementations?
Go To Implementations is an interesting algorithm that does a lot of different things and is a bit hard to explain holistically. The two commands are similar in that they both avoid returning ambient results. However, Go To Implementations uses Find All References under the hood to (among other things) search for values that satisfy some type. Go To Source Definition mostly uses Go To Definition under the hood, which traces variables/properties to their declarations and through imports/exports. It does not try to find the origin of every possible value that might come to inhabit that variable/property. The thing that makes Go To Source Definition different from every other command is that if Go To Definition returns only results in
.d.tsfiles, it will try again with a different module resolver that completely ignores.d.tsfiles, allowing it to find JS files that are otherwise “shadowed” by.d.tsfiles in your actual compilation.I’m a DefinitelyTyped maintainer. What can I do to increase the chances Go To Source Definition works on exports from my definitions?
Ensure the directory structure of your definitions is identical to that of the JS library you’re typing (at least as far as the public API goes). This means don’t move types out of
index.d.tsinto ahelpers.d.tsjust for code organization—helpers.d.tsshould only exist if it types ahelpers.jsfile. Conversely, if the JS library is broken up into many files that all get re-exported by the index/main file, declare your types in these files and re-export them too. (This is the correct way to author DT libraries anyway; Go To Source Definition compatibility is just a secondary benefit.)I’m a library author who ships my own types. What can I do to make Go To Source Definition work on exports from my library?
Consider if it’s appropriate to ship your TypeScript sources to npm. If you do, make sure you compile with
"declarationMap": trueand ship your.d.ts.mapfiles to npm too. When you do that, Go To Definition will already navigate to your.tssources, making Go To Source Definition unnecessary (it simply executes Go To Definition when this happens).