VSCode can't find references when using JSDoc

[FedericoGarciaGarcia]

Describe the bug

VS Code can't find references in Svelte files that are imported with JSDoc.

Example:

• Export class MyClass from utils.ts
• Import it in a component with TypeScript: ✅ works
• Import it in a component with JSDoc: ❌ fails

As shown in the screenshot below, the component importing MyClass with JSDoc (SampleJs.svelte) is not found. Only SampleTs.svelte is found:

Other ways of importing like /** @typedef { import('./utils').MyClass } MyClass */ don't work either.

I tried both the "Svelte for VS Code" extension and manually installing and setting up typescript-svelte-plugin

Reproduction

1. Export a declaration from a JS/TS file
2. Import it in a Svelte component with JSDoc
3. In the exporting file, right click the declaration and select "Find All References"
4. The Svelte component won't show up in "References"

Expected behaviour

The Svelte component should show up in "References"

System Info

• OS: macOS
• IDE: VSCode

Which package is the issue about?

Svelte for VS Code extension

Additional Information, eg. Screenshots

No response

[jasonlyu123]

Related to #2555 and #1033. The problem is that Svelte files are treated as using TypeScript in the typescript-svelte-plugin, where we add Svelte support for TypeScript files. But it should work if you trigger it from a Svelte file.

[FedericoGarciaGarcia]

Thanks for the reply!

But it should work if you trigger it from a Svelte file

Finding declarations from Svelte > JS does work, but for context in my case I have API calls and util functions defined in JS files that are imported by Svelte components. Whenever I make a change to these endpoints/utils I want to easily find all the components that use them.

For Svelte, is it better to migrate to TypeScript instead of continuing with JavaScript+JSDoc?

[jasonlyu123]

For Svelte, is it better to migrate to TypeScript instead of continuing with JavaScript+JSDoc?

It depends on whether you're bothered by this inconvenience. We have a fix for it #2565, but hesitant to merge it because of some error with TypeScript internal state check and potential breaking change.