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