Fix typedef binding with CJS exports=
#826
Conversation
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=`.
The big change is that, in Strada, non-top-level typedefs are also
exported. But it never made sense for these two scoped type aliases to
be exported, let alone *both*:
```js
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"
```
I'm not sure that I declared the local and export='d symbols in the
right way, so I'd appreciate expert opinions there.
There was a problem hiding this comment.
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
I'm adding this to show the changes, but I plan to revert it. The results are more correct, but the amount of code in the checker is twice the previous commit, so I don't think the improvement is worthwhile.
This reverts commit 1cffb6e.
|
Old PR, but is this still needed? |
|
Yes, it's still a problem when a typedef is in a file with |
|
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. |
means you fixed one failing test, and should run |
| case ast.KindQualifiedName: | ||
| qualified := name.AsQualifiedName() | ||
| symbol = c.resolveQualifiedName(name, qualified.Left, qualified.Right, meaning, ignoreErrors, dontResolveAlias, location) | ||
| symbol = c.resolveQualifiedName(name, qualified.Left, qualified.Right, meaning, ignoreErrors, location) |
There was a problem hiding this comment.
this is a driveby fix--dontResolveAlias wasn't used even before this PR
There was a problem hiding this comment.
In Strada I see dontResolveAlias being given both true and false all over the place. Are you sure we should remove it?
There was a problem hiding this comment.
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.
Probably only applies to TS, but just in case for JS (I couldn't come up with any examples, though).
5 participants
With this PR, top-level typedefs in file with commonjs exports (
module.exports=xorexports=x) are no longer added as exports of the file. They're added as exports of whatever isexport=. 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:
It's especially weird that a scoped alias would be inaccessible at the top-level, but then accessible in a different file.