docs: clean old configuration examples (#5626)

Author: ldez

Diff for: .golangci.reference.yml

@@ -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

Diff for: docs/src/docs/plugins/go-plugins.mdx

@@ -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.

Diff for: docs/src/docs/plugins/module-plugins.mdx

@@ -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:
@@ -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

Diff for: docs/src/docs/usage/false-positives.mdx

@@ -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.
 
@@ -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