gofumpt | stricter format than gofmt , while being backwards | Code Quality library

Why attempt to replace gofmt instead of building on top of it?. Our design is to build on top of gofmt, and we'll never add rules which disagree with its formatting. So we extend gofmt rather than compete with it. The tool is a modified copy of gofmt, for the purpose of allowing its use as a drop-in replacement in editors and scripts. Why are my module imports being grouped with standard library imports?. Any import paths that don't start with a domain name like foo.com are effectively reserved by the Go toolchain. Third party modules should either start with a domain name, even a local one like foo.local, or use a reserved path prefix. For backwards compatibility with modules set up before these rules were clear, gofumpt will treat any import path sharing a prefix with the current module path as third party. For example, if the current module is mycorp/mod1, then all import paths in mycorp/... will be considered third party. How can I use gofumpt if I already use goimports to replace gofmt?. Most editors have replaced the goimports program with the same functionality provided by a language server like gopls. This mechanism is significantly faster and more powerful, since the language server has more information that is kept up to date, necessary to add missing imports. As such, the general recommendation is to let your editor fix your imports - either via gopls, such as VSCode or vim-go, or via their own custom implementation, such as GoLand. Then follow the install instructions above to enable the use of gofumpt instead of gofmt. If you want to avoid integrating with gopls, and are OK with the overhead of calling goimports from scratch on each save, you should be able to call both tools; for example, goimports file.go && gofumpt file.go.