/cc @heschik

Yeah, this is unfortunate behavior, though I'm not sure I want to call it a bug. goimports tries to fix the imports for the file without needing to read anything from disk. To start, it ignores the persistent-cookiejar import (because it doesn't know the package name yet) and then is able to satisfy the import from the stdlib, at which point it can drop persistent-cookiejar. It should probably at least try to load the real package names in this situation. It's a little tricky because it still has to work if you refer to a nonexistant package.

The right workaround is to add the cookiejar name to the import statement.

Thanks for explanation, I use this workaround already :)

I thought some more about this and I don't think there's much room for improvement. At the moment, speed is a very high priority for goimports, and it puts a lot of effort into avoiding disk reads. To do that, it assumes that directory names correspond to package names, modified by some heuristics. If the directory name were cookiejar-persistent, the name would happen to agree with goimports' heuristics, and it would do the right thing. As it stands, this is a particularly unfortunate case where the directory name doesn't match, the real package name is in the standard library, and the APIs are the same because the package is a fork of the stdlib package.

The one idea I have is to require loads of package names where the heuristic is low confidence. But then if someone comes along with this package, but named persistentcookiejar (no hyphen), it's just as broken. So that's not too satisfying.

Sorry, but I think I'm going to just close this issue. I don't see a clear path forward and this is the first time I've seen this particular problem. We can absolutely revisit if it comes up again.