You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm afraid I don't think this belongs in Staticcheck. In my mind, the primary reason for renaming imports is to avoid conflicts — either with other imports, or with commonly used variable names. As such, what needs to be renamed, and what alias is the best fit, can vary on a file by file basis.
Imagine a package that already renames an import in various places and where the same import has to be renamed in a new file. But in the new file, the currently used alias would conflict with yet something else. It would be undesirable to have to stick with the alias just because it's common, and it would be even more undesirable to have to change the alias in all existing files to a new common one.
Imports in Go are file-local, and I think that justifies allowing file-local decisions as to the aliases used.
P.S. I see that your repository's readme lists this issue as "integration to linter aggregators". I'd like to point out that this isn't an aggregator, but a self-contained and cohesive set of checks, and we don't import the checks of other tools.
I would like to propose check that import aliases (renamed imports) are the same within same repository.
It works fairly well for large codebases.
There are false negatives though, due to limitation of go
analysis
toolchain to provide list of packages in single analysis run.However, there is no false positives. And it is fairly useful.
I saw issues in kubernetes and many other large codebases.
Cheers ! 🐱
https://github.com/nikolaydubina/consistentimports
The text was updated successfully, but these errors were encountered: