---
title: FAQ
---

## Which Go versions are supported

The same as the Go team (the 2 latest minor versions).

## How to use `golangci-lint` in CI

Run `golangci-lint` in CI and check the exit code. If it's non-zero - fail the build.

See [how to properly install `golangci-lint` in CI](/welcome/install/#ci-installation)

## `golangci-lint` doesn't work

1. Please, ensure you are using the latest binary release.
2. Run it with `-v` option and check the output.
3. If it doesn't help create a [GitHub issue](https://github.com/golangci/golangci-lint/issues/new) with the output from the error and #2 above.

## Why do you have `typecheck` errors?

`typecheck` is like a front-end for the Go compiler errors.
Compilation errors are identified/labeled as reports of `typecheck` but they are not produced by a linter called `typecheck`.

`typecheck` is not a linter, it doesn't perform any analysis,
it's just a way to identify, parse, and display compiling errors (produced by the `types.Checker`) and some linter errors.

It cannot be disabled because of that.

Of course, this is just as good as the compiler itself and a lot of compilation issues will not properly show where in the code your error lies.

As a consequence, the code to analyze should compile.
It means that if you try to run an analysis on a single file or a group of files or a package or a group of packages,
with dependencies on other files or packages of your project, as it doesn't compile (because of the missing pieces of code),
it also cannot be analyzed.

If there are `typecheck` errors, golangci-lint will not able to produce other reports because that kind of error doesn't allow it to perform any analysis.

How to troubleshoot:

- [ ] Ensure the version of `golangci-lint` is built with a compatible version of Go.
- [ ] Ensure dependencies are up-to-date with `go mod tidy`.
- [ ] Ensure building works with `go run ./...`/`go build ./...` - whole package.
- [ ] Ensure you are not running an analysis on code that depends on files/packages outside the scope of the analyzed elements.
- [ ] If using CGO, ensure all require system libraries are installed.

## Why running with `--fast` is slow on the first run

Because the first run caches type information. All subsequent runs will be fast.
Usually this options is used during development on local machine and compilation was already performed.

## How do you add a custom linter?

You can integrate it yourself, see this [manual](/contributing/new-linters/).
Or you can create a [GitHub Issue](https://github.com/golangci/golangci-lint/issues/new) and we will integrate when time permits.

## How to integrate `golangci-lint` into large project with thousands of issues

We are sure that every project can easily integrate `golangci-lint`, even the large one.

The idea is to not fix all existing issues. Fix only newly added issue: issues in new code.
To do this setup CI to run `golangci-lint` with option `--new-from-rev=HEAD~1`.

Also, take a look at option `--new`, but consider that CI scripts that generate unstaged files will make `--new` only point out issues in those files and not in the last commit.
In that regard `--new-from-rev=HEAD~1` is safer.

By doing this you won't create new issues in your code and can choose fix existing issues (or not).

## Why `--new-from-rev` or `--new-from-patch` don't seem to be working in some cases?

The options `--new-from-rev` and `--new-from-patch` work by comparing `git diff` output and issues.

If an issue is not reported as the same line as the changes then the issue will be skipped.
This is the line of the issue is not inside the lines changed.

To fix that you have to use the option `--whole-files`.

The side effect is the issues inside file that contains changes but not directly related to the changes themselves will be reported.
