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

[weswigham]

This works for one level of indirection to a local namespace-y thing, but what about an aliased namespacey thing? Eg

const mod = require("./mod.js")
/**
* @typedef {string} T
*/
module.exports = mod

or, abusing a ts construct to do it locally,

namespace ns {
  export namespace inner {}
}
import mod = ns.inner
/**
* @typedef {string} T
*/
module.exports = mod

mod's symbol will be an alias, and this will just patch the typedefs onto the alias symbol, and not the alias symbol's ultimate target, which, dollars to donuts, means it's going to effectively go missing without extra lookup logic in the checker, similar to what we used to have. 🥹

[sandersn]

Even simpler, this also reproduces the problem.

function f() { }
/** @typedef {string} T */
module.exports = f