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
Extended diagnostics quick fix #44941
Comments
This feature request is now candidate for our backlog! In the next phase, the community has 60 days to upvote. If the request receives more than 20 upvotes, we'll move it to our consideration list. You can find more details about the feature request process in our documentation. |
For tracking, @danieltre23 had a proof of concept put together to do this: danieltre23@52f6a7a |
Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends. Find more details about Angular's feature request process in our documentation. |
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage. We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package. You can find more details about the feature request process in our documentation. |
FYI we intend to deprecate the banana-in-box lint rule once auto-fixing is implemented: angular-eslint/angular-eslint#660 |
@JamesHenry Good to know! I've removed the |
…gnostics language server implementation for angular/angular#44941
…ostics language service implementation for angular#44941. A follow-up PR will be needed in the language server code to support this information.
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage. We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package. You can find more details about the feature request process in our documentation. |
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage. We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package. You can find more details about the feature request process in our documentation. |
FYI, I have opened PR #47393 to support fixing the invalid banana in box. |
The Angular compiler will report the invalid banana in box, this code fixes will try to fix the error and all the same errors in the selected file. Fixes angular#44941
The Angular compiler will report the invalid banana in box, this code fixes will try to fix the error and all the same errors in the selected file. Fixes angular#44941
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Which @angular/* package(s) are relevant/releated to the feature request?
compiler-cli, language-service
Description
Extended diagnostics often have a suggestion solution. This is by design, since they are intended to identify specific mistakes often made by developers with clear solutions or best practices. Since these fixes are so mechanical, we should give an easy, automated way to apply them to a diagnostic.
Proposed solution
Extended diagnostics should be able to generate a set of possible "quick fix" transformations which IDE's can use to address the diagnostic. In the case of
invalidBananaInBox
, we could automate a change like:@danieltre23 came up with a prototype in danieltre23@52f6a7a and was able to demo the feature. It's a relatively small commit so I don't think this is a significant amount of effort. The work here is to define the "quick fix" data type in the compiler, we'll need something custom since we don't want to depend on VSCode / LSP types here (curious how
tsc
does this?). The language service / VSCode extension will then need to transform the "quick fix" type into VSCode-compatible "code actions", which the IDE can show and apply with a single click.Alternatives considered
N/A
The text was updated successfully, but these errors were encountered: