-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
feat(es/parser): support type-only import/export specifiers #2309
Conversation
if orig_name.sym == js_word!("type") | ||
&& is!(self, IdentName) | ||
&& self.syntax().typescript() | ||
// invalid: `import type { type something } from 'mod'` |
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.
I think we should still parse this scenario even though it is invalid. It would be useful in dprint-plugin-typescript for example to parse this then convert import type { type something} from 'mod'
to import type { something } from "mod";
. Thoughts? (by the way, nice PR)
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.
I think dprint is a formatter, and it shouldn't accept code with invalid syntax.
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.
In the TS parser implementation they always parse this: https://github.com/microsoft/TypeScript/pull/45998/files#diff-12a6724be007eb1a19d80018c7a63bbc73525ca793a9b3e5da49a4e86bbf457c
That allows the language service and other code analysis to understand this code even though it might not be correct.
Then in the checker.ts code that's where they check if this is allowed: https://github.com/microsoft/TypeScript/pull/45998/files#diff-d9ab6589e714c71e657f601cf30ff51dfc607fc98419bf72e04f6b0fa92cc4b8R43439-R43450
Is there any harm in always parsing this even when it is a type-only import/export? I also think parsing this would align more with swc's type checker.
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.
I prefer that this would be syntax errors, but I'm OK to treat it as valid syntax, because this isn't a huge change.
The biggest annoying problem is that once I change the code, rustc will cost very very long time.
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.
It can be syntax error and can be valid ast in same time, and I think it's the right direction to go.
emit_err
can be used for such purpose.
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.
Thanks!
Parser changes LGTM, but I found some small issues about the role of crates.
if orig_name.sym == js_word!("type") | ||
&& is!(self, IdentName) | ||
&& self.syntax().typescript() | ||
// invalid: `import type { type something } from 'mod'` |
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.
It can be syntax error and can be valid ast in same time, and I think it's the right direction to go.
emit_err
can be used for such purpose.
I've used |
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.
LGTM. Thanks a lot!
Ref: microsoft/TypeScript#45998
This PR allows:
but rejects: