Skip to content

docs: clean old configuration examples #5626

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Mar 25, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 6 additions & 5 deletions .golangci.reference.yml
Original file line number Diff line number Diff line change
Expand Up @@ -415,11 +415,12 @@ linters:
# if check-error-free-encoding is set to true and errcheck linter is enabled,
# it is recommended to add the following exceptions to prevent from false positives:
#
# linters-settings:
# errcheck:
# exclude-functions:
# - encoding/json.Marshal
# - encoding/json.MarshalIndent
# linters:
# settings:
# errcheck:
# exclude-functions:
# - encoding/json.Marshal
# - encoding/json.MarshalIndent
#
# Default: false
check-error-free-encoding: true
Expand Down
33 changes: 18 additions & 15 deletions docs/src/docs/plugins/go-plugins.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -48,29 +48,32 @@ An example linter can be found at [here](https://github.com/golangci/example-plu
If you're looking for instructions on how to configure your own custom linter, they can be found further down.

1. If the project you want to lint does not have one already, copy the [.golangci.yml](https://github.com/golangci/golangci-lint/blob/HEAD/.golangci.yml) to the root directory.
2. Adjust the YAML to appropriate `linters-settings.custom` entries as so:
2. Adjust the YAML to appropriate `linters.settings.custom` entries as so:
```yaml title=.golangci.yml
linters-settings:
custom:
example:
path: /example.so
description: The description of the linter
original-url: github.com/golangci/example-linter
settings: # Settings are optional.
one: Foo
two:
- name: Bar
three:
name: Bar
version: "2"

linters:
settings:
custom:
example:
path: /example.so
description: The description of the linter
original-url: github.com/golangci/example-linter
settings: # Settings are optional.
one: Foo
two:
- name: Bar
three:
name: Bar
```

That is all the configuration that is required to run a custom linter in your project.

Custom linters are enabled by default, but abide by the same rules as other linters.

If the disable all option is specified either on command line or in `.golang.yml` files `linters.disable-all: true`, custom linters will be disabled;
If the disable all option is specified either on command line or in `.golangci.yml` files `linters.default: none`, custom linters will be disabled;
they can be re-enabled by adding them to the `linters.enable` list,
or providing the enabled option on the command line, `golangci-lint run -Eexample`.

The configuration inside the `settings` field of linter have some limitations (there are NOT related to the plugin system itself):
The configuration inside the `linters.settings` field of linter have some limitations (there are NOT related to the plugin system itself):
we use Viper to handle the configuration but Viper put all the keys in lowercase, and `.` cannot be used inside a key.
38 changes: 20 additions & 18 deletions docs/src/docs/plugins/module-plugins.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ An example linter can be found at [here](https://github.com/golangci/example-plu

- Define your building configuration into `.custom-gcl.yml`.
- Run the command `golangci-lint custom` (or `golangci-lint custom -v` to have logs).
- Define the plugin inside the `linters-settings.custom` section with the type `module`.
- Define the plugin inside the `linters.settings.custom` section with the type `module`.
- Run your custom version of golangci-lint.

Requirements:
Expand All @@ -31,43 +31,45 @@ plugins:
```

```yaml title=.golangci.yml
linters-settings:
custom:
foo:
type: "module"
description: This is an example usage of a plugin linter.
settings:
message: hello
version: "2"

linters:
disable-all: true
default: none
enable:
- foo
settings:
custom:
foo:
type: "module"
description: This is an example usage of a plugin linter.
settings:
message: hello
```

## The Manual Way

- Add a blank-import of your module inside `cmd/golangci-lint/plugins.go`.
- Run `go mod tidy` (the module containing the plugin will be imported).
- Run `make build`.
- Define the plugin inside the configuration `linters-settings.custom` section with the type `module`.
- Define the plugin inside the `linters.settings.custom` section with the type `module`.
- Run your custom version of golangci-lint.

### Configuration Example

```yaml title=.golangci.yml
linters-settings:
custom:
foo:
type: "module"
description: This is an example usage of a plugin linter.
settings:
message: hello
version: "2"

linters:
disable-all: true
default: none
enable:
- foo
settings:
custom:
foo:
type: "module"
description: This is an example usage of a plugin linter.
settings:
message: hello
```

## Reference
Expand Down
111 changes: 51 additions & 60 deletions docs/src/docs/usage/false-positives.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,6 @@ title: False Positives
---

False positives are inevitable, but we did our best to reduce their count.
For example, we have a default enabled set of [exclude patterns](/usage/configuration#command-line-options).

If a false positive occurred, you have the several choices.

Expand All @@ -17,106 +16,98 @@ Otherwise, some linters have dedicated configuration to exclude or disable rules
An example with `staticcheck`:

```yaml
linters-settings:
staticcheck:
checks:
- all
- '-SA1000' # disable the rule SA1000
- '-SA1004' # disable the rule SA1004
linters:
settings:
staticcheck:
checks:
- all
- '-SA1000' # disable the rule SA1000
- '-SA1004' # disable the rule SA1004
```

## Exclude or Skip
## Exclude

### Exclude Issue by Text

Exclude issue by text using command-line option `-e` or config option `issues.exclude`.
It's helpful when you decided to ignore all issues of this type.
Also, you can use `issues.exclude-rules` config option for per-path or per-linter configuration.

In the following example, all the reports that contains the sentences defined in `exclude` are excluded:

```yaml
issues:
exclude:
- "Error return value of .((os\\.)?std(out|err)\\..*|.*Close|.*Flush|os\\.Remove(All)?|.*printf?|os\\.(Un)?Setenv). is not checked"
- "exported (type|method|function) (.+) should have comment or be unexported"
- "ST1000: at least one file in a package should have a package comment"
```
You can use `linters.exclusions.rules` config option for per-path or per-linter configuration.

In the following example, all the reports from the linters (`linters`) that contains the text (`text`) are excluded:

```yaml
issues:
exclude-rules:
- linters:
- mnd
text: "Magic number: 9"
linters:
exclusions:
rules:
- linters:
- mnd
text: "Magic number: 9"
```

In the following example, all the reports from the linters (`linters`) that originated from the source (`source`) are excluded:

```yaml
issues:
exclude-rules:
- linters:
- lll
source: "^//go:generate "
linters:
exclusions:
rules:
- linters:
- lll
source: "^//go:generate "
```

In the following example, all the reports that contains the text (`text`) in the path (`path`) are excluded:

```yaml
issues:
exclude-rules:
- path: path/to/a/file.go
text: "string `example` has (\\d+) occurrences, make it a constant"
linters:
exclusions:
rules:
- path: path/to/a/file.go
text: "string `example` has (\\d+) occurrences, make it a constant"
```

### Exclude Issues by Path

Exclude issues in path by `issues.exclude-dirs`, `issues.exclude-files` or `issues.exclude-rules` config options.

Beware that the paths that get matched here are relative to the current working directory.
When the configuration contains path patterns that check for specific directories,
the `--path-prefix` parameter can be used to extend the paths before matching.
Exclude issues in path by `linters.exclusions.paths` or `linters.exclusions.rules` config options.

In the following example, all the reports from the linters (`linters`) that concerns the path (`path`) are excluded:

```yaml
issues:
exclude-rules:
- path: '(.+)_test\.go'
linters:
- funlen
- goconst
linters:
exclusions:
rules:
- path: '(.+)_test\.go'
linters:
- funlen
- goconst
```

The opposite, excluding reports **except** for specific paths, is also possible.
In the following example, only test files get checked:

```yaml
issues:
exclude-rules:
- path-except: '(.+)_test\.go'
linters:
- funlen
- goconst
linters:
exclusions:
rules:
- path-except: '(.+)_test\.go'
linters:
- funlen
- goconst
```

In the following example, all the reports related to the files (`exclude-files`) are excluded:
In the following example, all the reports related to the files (`paths`) are excluded:

```yaml
issues:
exclude-files:
- path/to/a/file.go
linters:
exclusions:
paths:
- path/to/a/file.go
```

In the following example, all the reports related to the directories (`exclude-dirs`) are excluded:
In the following example, all the reports related to the directories (`paths`) are excluded:

```yaml
issues:
exclude-dirs:
- path/to/a/dir/
linters:
exclusions:
paths:
- path/to/a/dir/
```

## Nolint Directive
Expand Down
Loading