Repository navigation
Odd quick fix ordering for misspelled identifiers #27614
Description
I believe that "misspelled identifier" quick fixes should precede the "remove unused declarations".
If anyone wants to take this on, this should just be a matter of
- Making a test case for this, and
- Shifting the order of which quick fix is registered first.
Activity
[-]Odd quick fixes for misspelled identifiers[/-][+]Odd quick fix ordering for misspelled identifiers[/+]jrkong commentedon Oct 10, 2018
I'd like to give this one a shot if no one's working on it. This is my first issue so I would really appreciate it if someone could direct me to the files I should look at to fix this.
RyanCavanaugh commentedon Oct 10, 2018
jrkong you just have to change the ordering of the codefix files in the various
tsconfig.jsonfiles undersrcjrkong commentedon Oct 11, 2018
Ryan Cavanaugh (@RyanCavanaugh) thanks a lot! That really helps, I'll do some digging.
jrkong commentedon Oct 11, 2018
So after spending a bit of time with the code I've discovered some odd inconsistencies with the behavior for this particular bug:
When I attempt to reproduce the bug with the given line in the issue this is what I see:
However if I added the lines:
the bug is reproduced.
Daniel Rosenwasser (@DanielRosenwasser) could you verify if I've reproduced the bug properly?
Here's where things got really odd for me:
Looking at the
src/services/tsconfig.jsonthe spelling code fixes are imported on line 54 and the code fixes for removing imports and unused dependencies are imported on line 62.So in theory
Change spelling to 'assertNever'should be loaded beforeRemove import from './Utilities'andDelete all unused declarations. What's more, the tests seem to corroborate that the source code is loading the spelling codefixes first:Here's a screenshot of the test I've been working on and how it currently fails.
I deliberately tried testing against the incorrect output to verify the behavior of the bug before I made any further changes but the tests seem to imply that
Change spelling to 'assertNever'should already. So does anyone have any idea what's going on?shonnungar commentedon Oct 5, 2021
Is this issue still up for grabs? Daniel Rosenwasser (@DanielRosenwasser)
DanielRosenwasser commentedon Oct 5, 2021
I think from the conversation above, this issue is too involved and needs some actual discussion at an editor sync first.
DanielRosenwasser commentedon Oct 6, 2021
One idea we had in the editor sync: an editor could ask about diagnostics with narrower spans than wider spans.
Another: an editor could provide multiple diagnostics and ranges it's interested in fixing in one call; that way the server could fix this.
Another-nother idea: editor provides a range, TypeScript just tries to fix all error codes.
Another-nother-nother idea: because error spans can drift, it might be better to just ask for the error code.
But overall, we need to get a better idea from how editors have implemented this.
There might be some inspiration from how refactorings work.
RyanCavanaugh commentedon Dec 3, 2025
Closing language service bugs related to the 6.0 implementation. For more information, see #62827