Fix hover on module.exports

[ahejlsberg]

This PR fixes our odd behavior when hovering on module.exports in a JS file. Previously we'd display { "exports=": { ... } }, now we display module "xxx" when hovering on module and exports: { ... } when hovering on exports. In addition, find-all-references on module finds all locations where the module is imported.

The PR also fixes the following panic:

module.exports = {}
exports.foo = 42 // Click on `exports` causes panic

[ahejlsberg]

The many baseline changes are all because module.exports now resolves to the symbol for the module source file instead of a synthetic module.exports symbol with no associated declaration.

[jakebailey]

Kind of funky that before, module.exports was module.exports and module was export=, but now module.exports is export= and module is module name...

[ahejlsberg]

I think the new behavior is defensible. The old one--not so much.

[Copilot]

Pull Request Overview

This PR fixes the hover display behavior for module.exports in JavaScript files and resolves a panic that occurred when clicking on exports after a module.exports = {} assignment. The fix changes how the module identifier is symbolized - previously showing Symbol(module.exports), it now displays Symbol("moduleName", Decl(...)) with the actual module name, making hover information clearer and enabling find-all-references functionality.

Key changes:

• Updated symbol representation for module in module.exports expressions across all CommonJS patterns
• Changed from generic Symbol(module.exports) to specific Symbol("moduleName", Decl(...)) format

[jakebailey]

Seems like you fixed a test and just need to run npm run updatefailing.

[ahejlsberg]

Seems like you fixed a test and just need to run npm run updatefailing.

Tried, but didn't seem to do anything.

[ahejlsberg]

Hmm, I'm not understanding what to do here! No changes are generated when I run npm run updatefailing.

[jakebailey]

I think this is a bad interaction of the script and baselines (since generating new baselines also fails the test, and the CI check is smarter)

We can fix this manually for now; remove the test from the failing list, then also remove the t.Skip() call from the generated test itself, then if you run the test you can accept the baselines. Then you can rerun updatefailing again.

I'll look into fixing this properly later.