reviewdog: A Language-Agnostic Bridge Between Linters and Code Review

What reviewdog Actually Solves

Most CI pipelines run linters, but the results often sit in a log file that nobody reads. Reviewdog closes that gap by taking the output of any linter, filtering it against the current diff, and posting only the relevant findings as comments on the code hosting service. This is useful for engineers who want to see lint errors inline on a pull request without switching to a separate dashboard. It is language-agnostic: the README states it integrates with 'any linter tools with ease.' The core value is not in detecting issues, but in routing and presenting them. If you already have a linter you trust, reviewdog makes its output actionable in the review workflow.

The Mechanism: errorformat, Diff Filtering, and Reporters

Reviewdog reads linter output from stdin and parses it using errorformat, a port of Vim's errorformat feature. The README gives the example of golint output in the format `{file}:{line number}:{column number}: {message}`, which maps to `%f:%l:%c: %m`. This parsing is the first layer. The second layer is diff filtering: reviewdog only posts findings that appear in the lines changed by the patch. The README shows a command like `golint ./... | reviewdog -efm="%f:%l:%c: %m" -diff="git diff FETCH_HEAD"`. That means a linter can flag a pre-existing issue in a file, but if that line is not part of the current diff, reviewdog will not post it. The third layer is the reporter. A reporter decides where the comment goes: local output, GitHub PR checks, GitLab MR discussions, or Bitbucket code reports. This separation of parsing, filtering, and reporting is the architectural core. Each stage is independent, which is why reviewdog can plug into so many different CI systems.

Getting It Running: Installation and First Command

The README offers several installation paths. The quickest is a curl script: `curl -sfL https://raw.githubusercontent.com/reviewdog/reviewdog/fd59714416d6d9a1c0692d872e38e7f8448df4fc/install.sh | sh -s`. That installs the latest version into `./bin/` by default. You can specify a directory and version with the `-b` flag. There is also a Homebrew tap: `brew install reviewdog/tap/reviewdog`, and a Scoop package for Windows. For Go users, `go install github.com/reviewdog/reviewdog/cmd/reviewdog@latest` works. A minimal local run is: `golint ./... | reviewdog -efm="%f:%l:%c: %m" -diff="git diff FETCH_HEAD"`. That filters lint results against your uncommitted changes and prints only the relevant findings to stdout. For GitHub Actions, the README points to a separate action, `reviewdog/action-setup`, which installs reviewdog and lets you define the linter step in a workflow. The config file, mentioned in the table of contents, is not detailed in the provided material, so you would need to consult the repository for its exact schema.

Reporters: Where the Comments Land

Reviewdog supports multiple reporters, each targeting a different hosting service. The default is `-reporter=local`, which prints filtered findings to stdout. For GitHub, there are several options: `github-pr-check` for PR checks, `github-check` for checks on any commit, `github-pr-review` for pull request review comments, and `github-annotations` for annotations on the checks API. The distinction matters. `github-pr-review` posts inline review comments, which appear as a single review on the PR. `github-pr-check` uses the checks API and may show annotations in the checks tab. The README also lists GitLab reporters: `gitlab-mr-discussion` for merge request discussions and `gitlab-mr-commit` for commit-level comments. Bitbucket gets `bitbucket-code-report` for code insights reports. This variety is a strength, but it also means you need to understand the permission model of each service. For example, posting a PR review comment on GitHub requires a token with the right scopes. The README does not spell out those scopes, so you will need to check the documentation for each reporter.

A Real Limitation: The errorformat Learning Curve

The biggest hurdle is not installing reviewdog, but writing the errorformat string for your linter. The README shows a simple case, but real linters often produce multi-line messages, or they include severity levels, or they emit warnings without a column number. The errorformat port from Vim is powerful, but it is also a mini-language of its own. You have to learn tokens like `%f`, `%l`, `%c`, `%m`, and the README hints at more complex patterns by linking to the full errorformat documentation. If your linter's output is not regular, you may spend more time debugging the efm than you save on review comments. Also, the diff filtering is line-based. If your linter reports a range or a block, reviewdog may only match the start line. That can cause false negatives. The README does not claim to handle multi-line findings, so you should test with your linter's actual output before relying on it.

Alternatives: GitHub Actions Annotations and Review Bots

A direct alternative is to use GitHub Actions' built-in annotations. You can run a linter in a workflow and use `actions/upload-artifact` or the `error-matcher` feature to surface findings as annotations on the checks tab. That approach does not require a separate tool, but it lacks the diff filtering that reviewdog provides. Without that filter, you get every finding in the file, not just the ones in the changed lines. Another alternative is a review bot like `github-actions-bot` or a custom script that parses linter output and posts a comment via the GitHub API. That gives you full control, but you are reinventing the parsing and filtering logic that reviewdog already has. The key difference is that reviewdog is a dedicated, maintained tool with a defined input format, while a custom script is a one-off that you must maintain. If you only use GitHub and your linter output is simple, the built-in annotations might be enough. If you need diff filtering or support multiple hosting services, reviewdog is the more complete answer.

Maintenance and Upgrade Cost

Reviewdog is written in Go and distributed as a single binary, which keeps deployment simple. The project is actively maintained, with v0.21.0 released on 2025-09-03, and there is a nightly release channel for those who want the latest changes. The README mentions a CHANGELOG.md, so you can track breaking changes. The upgrade cost is low in terms of installation: you can pin a version in your CI script or use the action-setup with a specific version. However, the errorformat strings you write may break if your linter changes its output format, not because of reviewdog itself. The config file, if you use one, may also evolve between versions. The license is MIT, which means you can use it in commercial projects without restrictions, but you should review the license file for any conditions. There is no indication of a paid tier or enterprise support, so you rely on community maintenance. Given the release cadence, the project appears healthy, but you should pin a version and test upgrades in a staging environment.

Editorial conclusion

Adopt reviewdog if your team already runs linters in CI and wants those findings posted directly on pull requests or merge requests, especially if you use GitHub Actions or GitLab CI. Avoid it if you need a full static analysis platform with built-in rules, or if your linter output is too irregular to map to errorformat without significant effort. Before adopting, verify that your linter's output format can be expressed with the available errorformat tokens, test the diff filtering locally with a sample diff, and confirm that the chosen reporter (e.g., github-pr-review) works with your repository's permission model. The project is actively maintained, with recent releases in 2025, but you should pin a version and review the changelog for breaking changes.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes