Skip to content

Fix values and types merging in JS module exports #37896

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Apr 24, 2020

Conversation

andrewbranch
Copy link
Member

I don’t think this is exactly right, but it’s probably closer than what was there before. Opening to create a context to chat about this with @sandersn.

Fixes #37833

Copy link
Member

@sandersn sandersn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like the right approach for a fix. I think the real, underlying problem is that module.exports doesn't create real aliases, but that's much more work to fix comprehensively.

I'd follow this up with a user test run.

@andrewbranch
Copy link
Member Author

@typescript-bot user test this

@typescript-bot
Copy link
Collaborator

typescript-bot commented Apr 22, 2020

Heya @andrewbranch, I've started to run the parallelized community code test suite on this PR at c6f7c82. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

Copy link
Member

@sandersn sandersn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The basic idea is good, just a couple of things I'd like to know about.

isEffectiveModuleDeclaration(target.valueDeclaration) && !isEffectiveModuleDeclaration(source.valueDeclaration))) {
!(source.valueDeclaration.flags & NodeFlags.Ambient && !(target.valueDeclaration?.flags & NodeFlags.Ambient)) &&
(isAssignmentDeclaration(target.valueDeclaration) && !isAssignmentDeclaration(source.valueDeclaration) ||
isEffectiveModuleDeclaration(target.valueDeclaration) && !isEffectiveModuleDeclaration(source.valueDeclaration)))) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this need a fix in the binder too? It probably only applies to code that is js-only (assignment declarations) and ts-only (ambient declarations) so 99.9% of the time it'll be in different files, but for the 0.01%, we do understand ambient declarations in .js as well -- we just put an error on them.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, how would you end up with an ambient declaration in a JavaScript file? Off the top of my head I didn’t think that was possible.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, we'll parse and understand this in JS:

declare function f(): void
f()

Just with lots of errors saying "please don't use this".

More practically, I think it would be better if this code and the check inside declareSymbol in the binder were the same -- if they haven't already diverged too far.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic in those two places was identical, so it was safe and easy to move to a utility. That said, I couldn’t actually trigger the same crash by writing ambient code in a JS file, I think because an ambient module declaration is only a module augmentation if the file is an ES module, and if it’s an ES module, module.exports is ignored.

@andrewbranch andrewbranch marked this pull request as ready for review April 23, 2020 23:40
@sandersn
Copy link
Member

Since I'm out tomorrow and the beta is done tomorrow, go ahead and merge this if there's no easy reconciliation between the module priority code in mergeSymbol and declareSymbol. We probably should dedupe the code, but if it's anything but trivial, it's a risky change.

@andrewbranch andrewbranch merged commit ce95d9c into microsoft:master Apr 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Auto-import failure: Cannot read property 'length' of undefined
3 participants