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
x/tools/cmd/goimports: imports current package when moving a package #12653
Comments
I'm sorry, I don't understand what you mean. Could you give a small example where goimports does the wrong thing? |
I'm sorry too, Let's see if my examples are better than my explanations. package utils
func A() {
} in another package we have: package not_utils
import "example.com/project/utils"
func B() {
utils.A() // caling the utils package
} Wanting to move package utils
func B() {
utils.A()
} and then running goimports against the file(saving in vim) will put the import in again. package utils
import "example.com/project/utils"
func B() {
utils.A()
} Given that importing the package a file is from is an import cycle I think that goimports should not do it and even remove such an import. |
A few thoughts:
|
goimports is automatically ran on every save of vim - a vim-go feature which has only this downside. The problem mostly arises because I move a whole file (with not only one reference of the 'utils' package) and then I open it up in vim to change the package name - upon writing I would prefer if the current package is not imported - this will make all references to 'utils' inside the file be erroneous I think that is better, than the current situation where it will be imported and than vim will show the file to be fine, but there will be an import cycle. My problem is mostly with vim-go and gorename(or another tool) not supporting moving between packages. But I still think goimports shouldn't import the current package. I also consider 'utils_test' to be different (and special) package altogether, I don't know how goimports handles that case though. |
I think this was resolved in #30663. Please comment if you disagree. |
A common case (for me at least) is for code to be written in a given package and than to be moved to another package.
Coping the code (+ changing the package) works great, but if the code was depending on the package it was moved into, go will die with import cycle.
Removing the package and running goimports adds it again - this for me happens on saving the file.
It seems reasonable that importing the current package is not desirable and in my setup (vim + vim-go) the file looks OK in vim even though it's not.
I propose goimports to remove(not add) the current package.
The text was updated successfully, but these errors were encountered: