Usage references can't be found for symbols exported through an exported namespace

[Andarist]

🔎 Search Terms

references exports namespace usage definition

🕗 Version & Regression Information

• This is the behavior in every version I tried

⏯ Playground Link

https://www.typescriptlang.org/play/?module=1#code/PTAEAEFsHsBMFcA2BTAXKAxtSMB2ArAZwChkAPAB2gCcAXUAXlACVkBDDWgbmONmQyI21ZKFxtIyQhQ6jWHegG9ioUADN4uTgEtouUMABUARkNghALwCeACgCU6AG7RtsHgF9e2yFTqhFoJZWoO7q1NigAEQAdMDauBTwtJE8xEYATGaBbNb2PEA

💻 Code

/// <reference path="fourslash.ts" />

// @module: commonjs

// @Filename: /mod.d.ts
//// export = React;
////
//// declare namespace React {
////   function /*1*/lazy(): void;
//// }

// @Filename: /index.ts
//// import { /*2*/lazy } from "./mod"
//// /*3*/lazy();

verify.baselineFindAllReferences("1", "2", "3");

🙁 Actual behavior

No usage references are found at 1 but the original definition gets nicely found on both 2 and 3

🙂 Expected behavior

I'd expect all 3 markers to return consistent results.

Additional information about the issue

No response

[mag123c]

I've analyzed this issue and believe the root cause is that getSymbolAtLocation fails to resolve symbols when ES6 named imports are used with export = namespace patterns.

I'm thinking of adding fallback logic in findAllReferences.ts to handle this case. Would this approach be acceptable, or is there a preferred way to handle export= + namespace symbol resolution?

--

Update: I've implemented a draft solution and created a Draft PR with the fallback logic approach mentioned above.

The implementation adds symbol resolution fallback in findAllReferences.ts when standard getSymbolAtLocation fails for import specifiers from export= modules.

Draft PR: #62412 - Would appreciate feedback on whether this approach is on the right track before finalizing

[tomas-correia]

I'd like to add that this issue also occurs when, for example, doing this:

// index.js
import * as redis from './client.js';

export default redis;

Using the as keyword I believe creates a new object with the same functions exported in another module. This doesn't mean VS Code shouldn't be able to find references to those functions, when doing for example:

// index.js
import redis from '@foo/redis';

redis.connect();

In this scenario, the intention is the same: to namespace the modules functions in an object named redis that is findable and auto-importable across the whole codebase.

If you do this:

// client.js
async function connect() {}
async function onConnect() {}

const redis = { connect, onConnect };

export default redis;

VS Code is able to find the references to those functions across the codebase - IF you click on the functions inside the redis objects, but NOT the declarations themselves.