For @types installing quickfix, only activate for implicit-any module #19394
Conversation
ghost
requested a review
from 
|
This is the opposite of my proposal on #19378. I believe Instead, I propose we remove this action from refactorings and for now leave the quick fix implementation to only work when there is a diagnostic error in the code |
|
@mhegazy Should we just disable the refactoring in |
I am not sure i understand this statement.. the way it is wired today, a quick fix is attached to a diagnostic message, and refactoring is one that is not attached to a diagnostic message. our design should make it such that the quick fix is only shown if there an error, and the refactoring should be shown otherwise. I am not sure i understand the problem in #19378 to be able to comment on either proposed solutions. |
ghost
mentioned this pull request
|
I can understand this distinction on implementation side of things but I'm coming at the problem from a ux/client perspective. Right now, VS Code presents both refactorings and quick fixes using the same lightbulb/code actions UI. However this may not always be the case. We have talked of creating a separate refactoring menu for example, and have also talked about changing the semantics of when refactorings are shown in the lightbulb menu. I believe TypeScript's concept of refactorings and quick fixes should correspond with what a user would understand these to be in their editor: a refactoring is a code action that changes your code's structure while a quick fix is a code action that addresses some sort of problem with the code. Classifying |
|
let's get this into release-2.6 as well. |
ghost
mentioned this pull request
Should fix the immediate issue in #19378. @mjbvz was getting an error since "lodash" wasn't resolving at all since he had classic module resolution set. Now we would not provide the codefix in that case (although we would still provide the refactoring).