As requested by @RyanCavanaugh on issue #24809 - reopening the issue with an updated concrete way to reproduce.
Tested with latest VSCode 1.43, latest typescript 3.8.3.
Simply create a .tsx file in VSCode with the following content:
import React from 'react'
const Thing: React.FC<{ text: string }> = (props) => <div>{props.text}</div>
const HelloWorld = () => <Thing text="hello world" />
And cmd+click on <Thing on line 5
Expected behavior:
Cursor moves to definition of const Thing on line 3.
Actual behavior:

VSCode opens a definitions window with links to 2 definitions:
React.FC, in node_modules/@types/react.This seems like a bug. In practice it means navigating is broken for JSX components, as cmd+clicking to link doesn't work - you have to cmd+click then click on the code definition again in the definitions window.
I am pretty sure that in the vast, vast majority of cases, when people cmd+click on the JSX for a component, they want to link to the component's definition and not the type.
Even supposing people did want to do that, in some cases:
So, there seems no downside here. Improve (fix) the most common usecase, less common (if ever) usecase still works, still 2 clicks.
I just want to bump this thread and say that I am also feeling this pain.
My click throughs are broken..
@davnicwil until this is fixed, you might appreciate that it is possible to hit enter after first click to go to file.
Not a great workaround but its something 馃槃
@nk1tz great shout - I'm probably doing this 100s of times a day so removing the friction even a little is really helpful. Cheers!
Can you clarify the workaround? I can't figure out how to get to the source file. I command+hover, it brings up some definitions, but I can't get anywhere from there (command clicking does nothing)
@JulianKingman cmd+click on the component itself (i.e. <Thing), it brings up the definitions (like in the screenshot), then pressing the enter key navigates to the actual component definition. Just saves you that second click in the definitions popup.
I'm experiencing this a few hundred times a day as well, It's a really frustrating experience.
Most of our React components are based on React.FC
Just wanted to bump the thread to say I am also experiencing this friction a lot; it's also frustrating that the first suggestion on the list is the result from node_modules/@types/react and not the actual line where const Thing = is defined.
A non-ideal workaround is to re-write it so that the function argument has the type definition:
const Thing = (props: React.PropsWithChildren<{ text: string }>) => (
<div>{props.text}</div>
);
const HelloWorld = () => <Thing text="hello world" />;
This avoids the problem where the definition lookup of <Thing> suggests the unwanted type from node_modules/@types/react. However, this workaround is a less specific type definition because the return value of the function doesn't have a type declared which isn't great.
Dealing with this all day long in a React TypeScript project. All components are typed React.FC and exported as default.
One fix that's helped is changing Editor > Goto Location: Multiple Definitions from peek to goto in settings.
Obviously, this will end up concealing some secondary definitions that might actually be useful to know about but in the meantime it makes command-clicking components behave as I would expect it to.
Most helpful comment
Dealing with this all day long in a React TypeScript project. All components are typed
React.FCand exported asdefault.One fix that's helped is changing
Editor > Goto Location: Multiple Definitionsfrompeektogotoin settings.Obviously, this will end up concealing some secondary definitions that might actually be useful to know about but in the meantime it makes command-clicking components behave as I would expect it to.