-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Update type-only import semantics to allow type queries #36092
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change looks OK to me, but with the caveat the I didn't review the original code so this is the first time for me to look at it. @weswigham should probably answer your question about whether there's a better way to finagle const enum references.
@typescript-bot perf test this |
Heya @andrewbranch, I've started to run the perf test suite on this PR at 124dcd6. You can monitor the build here. It should now contribute to this PR's status checks. Update: The results are in! |
@andrewbranch Here they are:Comparison Report - master..36092
System
Hosts
Scenarios
|
Check time appears up ~2–4%. I think this discussion will have some bearing on what we can do, so I’ll hold off on doing anything specifically for perf until we make some other decisions. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
For a moment I thought we could also allow type-only imports in class property declarations without initializers: class C {
[onInit]: any;
} But that’s actually a problem for ES class field semantics if I understand correctly. It’s also maybe worth noting that at this point, it would be very easy to allow people to use const enums as type-only imports (#36003), even though I think it’s pretty unintuitive. |
Yeah, that's definitely an error. Here's another fun case now that you mention non-emitted members in classes: import type { onInit } from "./framework-hooks";
abstract class Component {
abstract [onInit](): void;
} |
Edit: NodeFlag approach was terrible for incremental parsing. Reverted. |
@typescript-bot perf-test this |
a0691da
to
a5ca492
Compare
Looks like there's diagnostic conflicts |
@typescript-bot perf test this again for good measure please |
Heya @andrewbranch, I've started to run the perf test suite on this PR at be5f50f. You can monitor the build here. It should now contribute to this PR's status checks. Update: The results are in! |
@andrewbranch Here they are:Comparison Report - master..36092
System
Hosts
Scenarios
|
It doesn’t do this unless you set |
In #35200, a type-only import or export created a synthetic symbol which reflected only the type-side meaning of its target. This meant that the imported names were unusable in any value position. This PR removes the intermediate synthetic symbol and instead issues an error if the imported names appear in any non-ambient expression context. Namely, this allows for:
One oddity that arises with this approach is how to treat a namespace import that includes type-only exports:
Essentially, there is a limitation that if you need to access the value meaning of a type-only export, you can’t do so through a namespace import—you have to use a named (or default) import.
The distinction is subtle and confusing, but I think internally consistent, and unlikely to come up much in real code. At least, I think it’s better to start with this limitation than to be overly permissive in a way that could make the type system misrepresent the reality of the shape of a module.
Fixes #36040
Fixes #36003 (the part I said was a bug)
Fixes #36004