-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Organize type imports #55269
Organize type imports #55269
Conversation
Thanks for the PR! It looks like you've changed the TSServer protocol in some way. Please ensure that any changes here don't break consumers of the current TSServer API. For some extra review, we'll ping @sheetalkamat, @mjbvz, @zkat, and @joj for you. Feel free to loop in other consumers/maintainers if necessary. |
Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page. Also, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up. |
src/server/protocol.ts
Outdated
* Indicates where named type-only imports should sort. The default order ("inline") sorts imports regardless of if imports are | ||
* type-only. | ||
* | ||
* Default: `inline` |
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 current default is effectively "last"; for backwards compat I'm thinking we should probaby keep that?
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.
That makes sense to me, and is inline with the past changes to organize imports
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.
Of course, changing the default to inline was what I was doing when I was attempting to make this change, was very helpful in debugging.
This same code should also be affecting auto-imports; do we have enough test coverage for that? I'm not seeing any of those tests change which is suspicious as either it means that it's not working, or we're missing tests for auto-imports with type imports. |
…ganize-type-imports
…rganize-type-imports
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.
Looks pretty good to me! Just a couple notes
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.
Nice work!
src/server/protocol.ts
Outdated
@@ -3643,6 +3643,13 @@ export interface UserPreferences { | |||
* Default: `false` | |||
*/ | |||
readonly organizeImportsCaseFirst?: "upper" | "lower" | false; | |||
/** | |||
* Indicates where named type-only imports should sort. "inline" sorts imports without regard to if the import is |
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.
When you add the VS Code option for this, make sure to say “type-only named imports” or “type-only import specifiers” since “type-only imports” could also refer to the relative order of these:
import type a from "./a";
import b from "./b";
which IIUC is unaffected by this preference.
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.
Some of the orderings seem weird, but is that because they aren't sorted?
goTo.marker(""); | ||
|
||
verify.importFixAtPosition([ | ||
`import { A, D, type C, type B } from './foo'; |
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.
Why does this one turn out to have C first? The next one doesn't which feels odd.
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.
Since it's adding type B
and it's determined that the types are unsorted (since it specified inline
), it adds it on to the end. If the imports were unsorted before, it would always add onto the end, otherwise it might add the import somewhere weird in the middle, since we're not changing the order of the rest of the imports
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've stared at the tests and I think everything is in order.
Note that the other new import sorting options are not actually exposed in VS Code yet (you have to use the "unstable" field IIRC, see settings.template.json
), so I don't think we need to do that quite yet.
One thing I'm not sure I'm seeing is detection, in that we detect that imports are sorted "inline" and then use it. Am I missing that (there's a lot of tests...) or is that coming later?
Coming later! |
is |
I thought it was, but I guess it’s not. |
briefly discussed offline, and were reminded of #52115 (comment), so there's some more thinking to be done about how to expose the setting before we do |
Yep, that's my understanding. |
organizeImportsTypeOrder
can be specified as"first"
,"last"
, or"inline"
, with default behavior being type imports are sorted last.verifyImportFixAtPosition
(function used for testing)fixes #52820