goimports-reviser groups Go imports by std, general, company and project

goimports puts everything in one bucket, this splits it four ways

The problem is a small, persistent annoyance in Go codebases. The official goimports tool groups the standard library separately from everything else, which is enough for a single-purpose project. In a monorepo or a company codebase, that is not enough, because your own internal packages end up in the same group as third-party libraries, and a reader cannot tell at a glance which imports are yours. goimports-reviser is the tool for that case, described as a right imports sorting and code formatting tool and as a goimports alternative. The grouping is by 3 or 4 categories with their own linter, std for the standard library, general for general purpose libraries, company for libraries inside your organisation, which is optional, and project for your own local dependencies. The company group only exists if you tell it your prefixes, and when it does not exist the company imports sit inside the general group.

The company group is what makes it different

The distinguishing option is -company-prefixes, which creates a group for company imports, the libraries inside your organisation. The values should be comma-separated. The README's own example shows why this matters in practice: a file importing fmt, an experimental slices package, one package from the same GitHub organisation but a different repository, and a package from the current module, ends up with the same organisation's package and the local package both in the general bucket, indistinguishable. With the option set, the same organisation's package is pulled out into its own group, and the local project dependency is left alone. The tool takes the project boundary from a -project-name option, so it knows which import path prefix is your own code, and it has a matching -imports-order option to override the whole order if your convention is different.

One pass can also drop unused imports and rewrite aliases

The tool bundles three other jobs into the same run, which is what makes it a replacement for a two-step workflow rather than just a sorter. The -rm-unused option removes unused imports. The -set-alias option rewrites import aliases for versioned packages or for packages with an additional prefix or suffix, with the example given being opentracing aliased for github.com/opentracing/opentracing-go, and the options help text shows the versioned case where a package like github.com/go-pg/pg/v9 is imported as pg. The -format option performs additional formatting on the file, and the README says formatting is prepared so you do not need to use gofmt or goimports separately. There is also -separate-named to put named imports on their own line, and a -use-cache option for performance. The whole set of flags is documented in a single usage block, which is one of the more complete CLI references you will find on a small Go tool.

Running it on a file, a directory or the whole module

The command line is where the tool gets its range. The simplest form takes a file path as the last argument, and the README shows a single file being sorted with all three options enabled:

goimports-reviser -rm-unused -set-alias -format ./reviser/reviser.go

A directory can be targeted as well, and applying rules recursively to a directory needs the -recursive flag, while using ./... as the target applies recursively by default. The README also shows multiple targets in one invocation, with a file and a package pattern side by side, which is how you sort one generated file and a whole package in a single pass. The -excludes option takes a comma-separated list of files or directories to leave alone, with the example given as a git directory and a proto pattern. That matters for generated code, and there is a separate -apply-to-generated-files option for the opposite case, where a file whose first comment starts with the marker comment Code generated is included rather than skipped.

Three ways to install it, and one of them is a tap

Installation is covered three times over in the README. The Go route is the standard one, a go install of the module path at the latest version:

go install -v github.com/incu6us/goimports-reviser/v3@latest

The Homebrew route goes through a tap, which is a personal tap rather than homebrew-core, so it takes two commands. The Snap route is a single install command. The README also documents a Snapcraft badge, which tells you there is a published snap package maintained alongside the binaries. A fourth path is the JetBrains IDE integration, which the README describes through a file watcher plugin so that the tool runs on save. The repository layout backs the tool structure, with main.go and main_test.go at the root, a reviser/ directory for the sorter itself, a pkg/ directory holding a goanalysis package, a helper/ directory, and a Makefile full of cross-compilation targets that build both the command and the linter binary for 386, amd64 and arm64 across Windows, macOS and Linux.

A linter binary ships alongside the command

The Makefile reveals that this is two tools, not one. Almost every target in it builds pkg/goanalysis/analyzer.go into a binary called goimportsreviserlint, cross-compiled for windows-386, windows-amd64, macos-amd64, macos-arm64, linux-386, linux-amd64 and linux-arm64, while a separate set of targets builds the goimports-reviser command itself. The README refers to the linter in passing, in the description of the grouping categories as having their own linter, with the link pointing at the linter's own README. That is the goanalysis convention, a tool built with the analysis framework so it plugs into Go's analysis tooling and IDE diagnostics. The Go module confirms the shape, since it depends on golang.org/x/tools, which is the package that provides the analysis framework, alongside golang.org/x/mod and golang.org/x/exp. The module path carries a /v3 suffix, so this is the third major version of the tool.

The grouping model has named slots for edge cases

The -imports-order option deserves a closer look, because it is where the model shows its edges. The default value is std, general, company, project, and the option accepts a different order if your convention differs. Two extra slots exist beyond the four obvious ones. The blanked slot holds imports with an underscore alias, which is the convention for a deliberately unused import, and the dotted slot holds imports with a dot alias, which is the convention for importing a symbol into package scope. The option help spells out the meaning of each: std for the standard import group, general for general purpose libraries, company for inter-org or your company libraries, split into a fourth group if -company-prefixes is set and otherwise part of the general purpose libs, project for your local project dependencies, and blanked and dotted for the two alias styles. The linter that comes with the tool enforces this scheme rather than leaving it to review comments, and the README notes that comments on imports are acceptable so long as they are not documentation.

Editorial conclusion

goimports-reviser suits a Go team that has settled on a four-group import convention and wants a single tool to enforce it, especially in a repository with its own internal libraries that keep landing in the third-party group. It does not suit a team that just wants goimports, since the tool is described as an alternative rather than a drop-in for it, and it does not replace a real import-resolution tool, because it groups what is already imported rather than working out what should be imported. Before adopting, run it with the -list-diff option first to see which files it would touch, and note that the last push to the repository was on 2026-08-29 with release v3.13.2 tagged the same day.

Frequently asked questions

Official sources

1. incu6us/goimports-reviser on GitHub
2. Issues
3. License: MIT
4. README
5. Releases