Uh oh!
There was an error while loading. Please reload this page.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 that there is an argument to be made here that this codefix shouldn't change the position of the promoted import. This is a separate action. I left this as-is though, as I assume that this was implemented this way for a reason.
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 suppose it might be annoying to users if they have their imports already sorted such that type-only imports are grouped separately from regular ones; promoting a type import will leave it in the wrong position in the list. Particularly if the user is relying on auto-imports which automatically puts them in the correct place, it'd be frustrating to have this one code fix that requires triggering Organize Imports manually when in every other case it's automatic.
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 reason that it moves in the list currently is that TS's organize/auto-imports always sorts
typeimports at end, but otherwise they're in order. Of course, via #55269 and #52820, this will become even more configurable. So effectively, any operation that does anything to imports (adding, removing, changing modifiers) has to go through some sort of sorting code to determine whether or not the user opted into sorting something in a particular way. Thankfully, the main goal of that configurability is enabling people to stick type imports inline such that these modifier changes don't affect sorting at all, which is nice.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.
Do you happen to know if renaming exported symbols also sorts the relevant imports that use them?
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'm pretty sure it doesn't, no; my understanding is that rename is more of an "in place transform" and it doesn't even check that the name you're giving it is syntactically valid.