Cmd+click of JSX component shows type definition in VSCode, instead of linking to component definition

Ryan Cavanaugh (@RyanCavanaugh)

As requested by Ryan Cavanaugh (@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:

The component definition on line 3 (that I expected to be linked to)
The definition for the type of the component: 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:

Just seeing what the type is would be solved in one click, because it is there in the definition
Navigating to that type definition if you really wanted to would remain at 2 clicks - by just cmd+clicking it right there in the definition.

So, there seems no downside here. Improve (fix) the most common usecase, less common (if ever) usecase still works, still 2 clicks.

David Nicholas Williams (@davnicwil)

I just want to bump this thread and say that I am also feeling this pain.
My click throughs are broken..
David Nicholas Williams (@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 😄

Nate (@nk1tz)

Nate (@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

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 making jump to definition a constant chore.

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.

Sam Becker (@sambecker)

I would love for this to be resolved as well. Thanks Sam Becker (@sambecker) for the tip! That definitely helps as a workaround.

Hello guys, I made a simple vscode extension to resolve this problem. vscode-tsx-arrow-definition, and you can search vscode extension marketplace to find it.

This extension's function is simple:

If there're more than one defintions, and one definition is @types/react/index.d.ts, just remove it from the definition list.
If there's only one definition or no definition is @types/react/index.d.ts, just use the original result.

Hope this helps.

Sam Becker (@sambecker)

I've not had a problem with this because I've used "Goto" as mentioned above by Sam Becker (@sambecker). Suddenly today my "Goto" is defaulting to the @types/react/index.d.ts instead of the actual component, and it is driving me nuts.

Any solutions?
I'm not sure if something changed in VSCode or my project.

What determines the order of the definitions and can we reprioritize them?

A setting to state that anything in node_modules or *.d.ts should not be the first/default definition if multiple exist would be one way to solve this.

Michael Liquori (@mliq)

Michael Liquori (@mliq) I have also been using the "Goto" setting mentioned above and it was working perfectly until a few days ago. Suddenly the order seems to have changed and it is now preferring the node_modules definitions. I think something in VSCode must have changed.

Thanks Ding Yi (@Miaonster) for your extension, I tried it and it works well to filter out React specific types, however I also experience the problem with other type definitions which are in node_modules from other libraries. If your extension could be modified to either (1) filter out any match within node_modules, or (2) re-order the matches so that node_modules is at the bottom of the list, then it would be helpful to filter out definitions from libraries other than React.

Sam Becker (@sambecker)

I've not had a problem with this because I've used "Goto" as mentioned above by Sam Becker (@sambecker). Suddenly today my "Goto" is defaulting to the @types/react/index.d.ts instead of the actual component, and it is driving me nuts.

Any solutions?
I'm not sure if something changed in VSCode or my project.

What determines the order of the definitions and can we reprioritize them?

A setting to state that anything in node_modules or *.d.ts should not be the first/default definition if multiple exist would be one way to solve this.

That just recently stopped working for me as well. I think the latest version of vs code must have changed the order. I installed the vscode-tsx-arrow-definition extension that Ding Yi (@Miaonster) mentioned above and it seems to be working well for me.

Ben Cole (@bcole808)

Ben Cole (@bcole808) I can add a setting that will allow user ignore all node_modules or user-specified types if there are multi definitions.

Sorry but this shouldn't be handled by a plugin. It is great that Miaonster created it for the time being, but this needs a permanent out of the box solution. Maybe the dicussion should be moved/started in the vsc repo.

You don't get my point. All those "same here" comments aren't adding anything valuable to the problem discussion.
All participants gets notifications and are distracted from they work for no good reason.

The problem itself is super annoying and god bless that person who created plugin that fixes problem It's not a proper solution and should be fixed in vscode.

But until — just press 'subscribe' button in this issue and use plugin (if that problem hurts you bad enough)

You don't get my point. All those "same here" comments aren't adding anything valuable to the problem discussion.
All participants gets notifications and are distracted from they work for no good reason.

Sorry, but you didn't get my point first of all. I've added new information for this bug, that it's also reproducing with React.memo. I think, it's a good reason to write a comment.

And only a subscription is an incomprehensible signal about the urgency of the problem. You need to at least "like" the original post.

Sam Becker (@sambecker)

I've not had a problem with this because I've used "Goto" as mentioned above by Sam Becker (@sambecker). Suddenly today my "Goto" is defaulting to the @types/react/index.d.ts instead of the actual component, and it is driving me nuts.

Any solutions?
I'm not sure if something changed in VSCode or my project.

What determines the order of the definitions and can we reprioritize them?

A setting to state that anything in node_modules or *.d.ts should not be the first/default definition if multiple exist would be one way to solve this.

+1 . I remember I change the config to Goto in the past. And recently it suddenly not work.

Would love to see an official fix for this, or even progress towards one, cmd/ctrl + clicking was so useful until I started to wrap all my components with React.memo

I am in the process of converting to VS Code from IntelliJ IDEA and there's a lot of great things in VS Code, but not being able to consistently cmd + click to navigate to definition is driving me nuts.

In a project with TypeScript 5 and React 18, I had to use the plugin mentioned above (https://github.com/Miaonster/vscode-definition-filter), but with custom settings:

// settings.json
    "tsxDefinitionFilter.remove": [   
        "**/node_modules/@types/react/ts5.0/index.d.ts"
    ]

This problem is back for me.

Started happening to me as well, worked flawlessly until the last update.

Same here. Just started taking me to the @types/react node module definitions instead of the actual reference file.

Same here

Navigation Menu

Repository navigation

Cmd+click of JSX component shows type definition in VSCode, instead of linking to component definition #37816

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Cmd+click of JSX component shows type definition in VSCode, instead of linking to component definition #37816

Description

Activity

nk1tz commented on Apr 30, 2020

davnicwil commented on May 1, 2020

JulianKingman commented on May 1, 2020

davnicwil commented on May 2, 2020

varemenos commented on Sep 4, 2020

bcole808 commented on Nov 2, 2020

sambecker commented on Nov 7, 2020

apeqqut commented on Feb 12, 2021

Miaonster commented on Apr 4, 2021

mliq commented on Apr 7, 2021

bcole808 commented on Apr 7, 2021

jake-crane commented on Apr 7, 2021

Miaonster commented on Apr 8, 2021

5 remaining items

jodaka commented on Apr 16, 2021

tim-mukhin commented on Apr 19, 2021

MaoScut commented on Apr 29, 2021

zaytri commented on Oct 26, 2021

PaulMest commented on Apr 20, 2023

etothepii commented on Jan 9, 2024

yard2010 commented on Mar 7, 2024

piotrkulpinski commented on Mar 7, 2024

bernatfortet commented on Mar 14, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions