Just note that what goimports needs is a prefix. So if your package is something like github.com/segevfiner/magicgopher, then it needs to be set too github.com/segevfiner. It is also actually a comma-separated list for some more complex cases, so having a setting for it is still definitely useful. Though honestly, goimports should have detected a config file in the repository root or something (Which gopls would also support), so such a setting like that is shared across devs and different code editors without them having to set it up themselves or depend on some specific editor configuration sharing facility.

I personally wish -local had never been added. (@bradfitz may have his own opinion.) I don't particularly want to encourage its adoption. We're definitely not going to create a goimports config file without a much more compelling reason.

A setting that automatically sets -local from the module prefix is still a problem for anyone that works on some projects that use -local and some that don't. I would want there to be more demand before we considered adding it.

Why exactly don't people want to encourage -local? It seems to be a very common pattern to have 3 groupings. Couldn't something like -local-mod be added, to be equivalent to goimports -local $(go list -m)

A setting that automatically sets -local from the module prefix is still a problem for anyone that works on some projects that use -local and some that don't. I would want there to be more demand before we considered adding it.

I don't see how this would be a problem, we can add a flag named -auto-local or something like that and if that's used it just finds the local prefix from the module name and prepends it to the list of locals set by -local users would be in control, but this would allow people that want to use this functionality to have generic makefiles or IDE configuration that works consistently across their projects without special config...