cc @heschi @bradfitz @jayconrod

In my experience, someone in the world is using symlinks for every possible purpose. Ignoring them may or may not make sense, but doing it will probably annoy someone. And it won't actually make bazel work, since goimports won't be able to find generated code.

Unfortunately, without a way to predict the impact of the change, my inclination here is toward inaction. Sorry.

The bazel user community might be big enough to consider a goimports fork that understands bazel.

If you're expecting go to find packages in symlinked locations, you're already going to be running into problems because go mod tidy ignores symlinks and will probably remove a bunch of your dependencies. It'll also cause a problem for you if you don't have your generated code in the source tree, and the generated code has dependencies which go mod tidy then removes. I don't think it makes sense for goimports to consider paths which go mod tidy and go build do not - if you're depending on symlinks that way, your workflow is already broken (at least in module mode).

The situation I'm concerned with is the fairly common situation where a monorepo is built with bazel but developers working primarily on go parts of the repo still usually build with go build during iterative development, and want tools such as editor integrations which run goimports on save to still work correctly, in which case the generated code will still usually be checked in (or at least present in the source tree but maybe .gitignored).

And it won't actually make bazel work, since goimports won't be able to find generated code.

It's common for packages containing generated code to also contain code that isn't generated (at the very least, a source file with a //go:generate line). Thus, goimports would still be able to find the package. Plus there's plenty of projects that don't use generated code at all but would still like for goimports to work.