Skip to content
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

codeFixes for things that aren't diagnostics #19392

Closed
ghost opened this issue Oct 20, 2017 · 4 comments · Fixed by #22204
Closed

codeFixes for things that aren't diagnostics #19392

ghost opened this issue Oct 20, 2017 · 4 comments · Fixed by #22204
Labels
Fixed A PR has been merged for this issue Suggestion An idea for TypeScript

Comments

@ghost
Copy link

ghost commented Oct 20, 2017

TypeScript Version: 2.7.0-dev.20171020

Code

function f(x) {}

It would be nice to have a codeFix to fix implicit-any instead of a refactoring. I believe a refactoring requires you to highlight the thing in question, which isn't easily discoverable.
Currently codeFixes work by iterating over errors; but in this case we would want to produce one even in an error-less build.
This would also help us avoid having to create codeFix / refactor pairs for things such as installing types for implicit-any packages.
We could also generate "info" errors (ref: #14501) that don't surface normally and make codeFixes for those.

CC @mjbvz

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Oct 20, 2017

@amcasey was talking about how this is enabled with "info" diagnostics in Roslyn

@amcasey
Copy link
Member

amcasey commented Oct 20, 2017

I asked about this at today's design meeting and the consensus seemed to be that we should create a separate (linter-like) tool to detect such cases and then offer to fix them (i.e. that this doesn't belong in the compiler).

@ghost
Copy link
Author

ghost commented Oct 20, 2017

It wouldn't be easy to create a separate tool to detect implicit-any without duplicating code from the compiler -- unless you clone the project, change the compiler options, and type-check again, which is what tslint's no-unused-variable currently does. But that rule is slow and thus not enabled by default; supporting a lint rule for every compiler option like that would result in a lot of clones.

@amcasey
Copy link
Member

amcasey commented Oct 20, 2017

I understood that we proposed to add new compiler APIs (e.g. getImplicitAnyDeclarations) on a case-by-case basis as we determined that doing the work in a separate tool was infeasible. I believe it was @mhegazy who brought it up.

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Fixed A PR has been merged for this issue Suggestion An idea for TypeScript
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants