-
Notifications
You must be signed in to change notification settings - Fork 509
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
Unused import rules does not remove all imports #1754
Comments
I think both of it. Of course it is technically possible to implement such a feature because the IntelliJ IDEA and Android Studio are both able to do it as well. But I expect that the cost of implementing it is unacceptable high in man hours and complexity. Ktlint has one important restriction when linting/formatting the file. All information required should literally be available in the PSI file produced by the embedded kotlin provider. Lookin up information in other files in the project or in included dependencies does not fit in the scope of ktlint. From that perspective, I stronger and stronger believe that the Of course my analysis above might be wrong. So if somebody contributes a Pull Request with actually guarantees that only unused imports are removed, then I am willing to consider to merge that into Ktlint (but only if the added complexity is reasonable with regard to the functionality). |
Also see #1529 |
Expected Behavior
I have found that the unused import rule does not remove all unused imports. I think this is related or the same issue as #1587.
Observed Behavior
The imports not removed are
import co.[ID].data.session.isLoggedIn
import kotlinx.coroutines.flow.collect
import androidx.compose.runtime.getValue
import androidx.compose.runtime.setValue
They are removed via android studio optimize imports but not by ktlint. I ran ktlint 48 through the terminal to test
Posted in the kotlin slack https://kotlinlang.slack.com/archives/CKS3XG0LS/p1672347793114019
It appears that some imports are not going to be removed.
Summary
Does that mean its not worth the effort or its literally impossible? Is there something that can get exposed to you to make this possible? If the issue is that it would require a large refactor I think it would be valuable to know where in the code the limitation and how to resolve the limitation so someone can consider putting out a PR?
Also should we update the documentation to reference the current limitations? I am not sure I understand the rules of the limitations
The text was updated successfully, but these errors were encountered: