Fix typedef binding with CJS exports=

[sandersn]

With this PR, top-level typedefs in file with commonjs exports (module.exports=x or exports=x) are no longer added as exports of the file. They're added as exports of whatever is export=. I'm not sure that I declared the local and export='d symbols in the right way, so I'd appreciate expert opinions there.

The big change compared to Strada is that only top-level typedefs are exported. But it never made sense for these two scoped type aliases to be exported, let alone both:

function one() {
  /** @typedef {string} T */
  /** @type {T} */
  var s = 's'
}
function two() {
  /** @typedef {number} T */
  /** @type {T} */
  var n = 1
}
/* @type {T} */
var error = "I AM ERROR"

It's especially weird that a scoped alias would be inaccessible at the top-level, but then accessible in a different file.

[Copilot]

Pull Request Overview

This pull request updates the typedef binding behavior in CommonJS modules so that only top-level typedefs are exported via the export= assignment, correcting unintended exports of scoped typedefs. Key changes include updating baseline error files to reflect the new behavior and modifying binder.go to delay binding of JSTypeAliasDeclarations when the file is a CommonJS module.

Reviewed Changes

Copilot reviewed 44 out of 55 changed files in this pull request and generated 2 comments.

File	Description
testdata/baselines/reference/submodule/...errors.txt	Updated error messages and counts reflecting removal of extra export assignment issues
internal/binder/binder.go	Introduced delayed binding for JSTypeAliasDeclarations and added delayedBindJSDocTypedefTag to bind typedefs conditionally

Files not reviewed (11)

• testdata/baselines/reference/submodule/compiler/checkJsTypeDefNoUnusedLocalMarked.errors.txt: Language not supported
• testdata/baselines/reference/submodule/conformance/importingExportingTypes.symbols: Language not supported
• testdata/baselines/reference/submodule/conformance/importingExportingTypes.symbols.diff: Language not supported
• testdata/baselines/reference/submodule/conformance/jsDeclarationsImportAliasExposedWithinNamespace.symbols: Language not supported
• testdata/baselines/reference/submodule/conformance/jsDeclarationsImportAliasExposedWithinNamespace.symbols.diff: Language not supported
• testdata/baselines/reference/submodule/conformance/jsDeclarationsImportAliasExposedWithinNamespaceCjs.symbols: Language not supported
• testdata/baselines/reference/submodule/conformance/jsDeclarationsImportAliasExposedWithinNamespaceCjs.symbols.diff: Language not supported
• testdata/baselines/reference/submodule/conformance/jsDeclarationsImportTypeBundled.errors.txt: Language not supported
• testdata/baselines/reference/submodule/conformance/jsDeclarationsTypeAliases.errors.txt: Language not supported
• testdata/baselines/reference/submodule/conformance/jsDeclarationsTypedefAndLatebound.errors.txt: Language not supported
• testdata/baselines/reference/submodule/conformance/jsDeclarationsTypedefPropertyAndExportAssignment.types: Language not supported

[jakebailey]

Old PR, but is this still needed?

[sandersn]

Yes, it's still a problem when a typedef is in a file with module.exports=. I should look at this again, because the declaration emit and reparser are finished now.

[sandersn]

What does a failure in the generate shtage mean? There's now an unexpected diff, but I don't know what causes diffs to appear.

[jakebailey]

 internal/fourslash/_scripts/failingTests.txt                     | 1 -
 internal/fourslash/tests/gen/javascriptModulesTypeImport_test.go | 2 +-

means you fixed one failing test, and should run npm run updatefailing and commit that result

[sandersn]

this is a driveby fix--dontResolveAlias wasn't used even before this PR

[jakebailey]

In Strada I see dontResolveAlias being given both true and false all over the place. Are you sure we should remove it?

[sandersn]

Yes. As best I can tell, it's a translation artifact--resolveQualifiedName is a function extracted from resolveEntityName -- it reads way better in Go and probably would in TS too -- but its code never actually refers to dontResolveAlias, even in Strada. It's only checked once in resolveEntityName, actually, right at the end, when deciding whether to resolveAlias on the symbol we just resolved.