feat: migrate to golangci-lint v2 config format

00-empty/.golangci.yml

@@ -4,9 +4,11 @@
 # Author: @ccoVeille
 # License: MIT
 # Variant: 01-defaults
-# Version: v1.1.0
+# Version: v2.0.0
 #
-# empty file to force using the default settings
+# this file to force using the default settings
 # otherwise golangci-lint looks for .golangci.yaml files
 # in parent folders
 # this may cause issues
+
+version: "2"

01-defaults/.golangci.yml

@@ -4,20 +4,18 @@
 # Author: @ccoVeille
 # License: MIT
 # Variant: 01-defaults
-# Version: v1.1.0
+# Version: v2.0.0
 #
+version: "2"
+
 linters:
   # some linters are enabled by default
   # https://golangci-lint.run/usage/linters/
   #
-  # enable some extra linters
   enable:
     # Errcheck is a program for checking for unchecked errors in Go code.
     - errcheck
 
-    # Linter for Go source code that specializes in simplifying code.
-    - gosimple
-
     # Vet examines Go source code and reports suspicious constructs.
     - govet
 
@@ -26,3 +24,6 @@ linters:
 
     # It's a set of rules from staticcheck. See https://staticcheck.io/
     - staticcheck
+
+    # Checks Go code for unused constants, variables, functions and types.
+    - unused

01-defaults/README.md

@@ -12,12 +12,11 @@ Source: [@ccoVeille](https://github.com/ccoVeille/golangci-lint-config-examples)
 
 ## Enabled linters
 
+These are the default ones:
+
 ### errcheck
  Errcheck is a program for checking for unchecked errors in Go code.
 
-### gosimple
- Linter for Go source code that specializes in simplifying code.
-
 ### govet
  Vet examines Go source code and reports suspicious constructs.
 
@@ -27,4 +26,5 @@ Source: [@ccoVeille](https://github.com/ccoVeille/golangci-lint-config-examples)
 ### staticcheck
  It's a set of rules from staticcheck. See https://staticcheck.io/
 
-
+### unused
+ Checks Go code for unused constants, variables, functions, and types.

02-basic/.golangci.yml

@@ -4,9 +4,39 @@
 # Author: @ccoVeille
 # License: MIT
 # Variant: 02-basic
-# Version: v1.1.0
+# Version: v2.0.0
 #
+version: "2"
+
+formatters:
+  enable:
+    # format the code with Go standard library
+    - gofmt
+
 linters:
+  exclusions:
+    # these presets where present in the v1 version of golangci-lint
+    # it's interesting to keep them when migrating, but removing them should be the goal
+    presets:
+      # exclude check on comments format in godoc
+      # These are common false positives in poor code
+      # you should not use this on recent code you write from scratch
+      # More information: https://golangci-lint.run/usage/false-positives/#comments
+      - comments
+
+      # Common false positives
+      # feel free to remove this if you don't have any false positives
+      # More information: https://golangci-lint.run/usage/false-positives/#common-false-positives
+      - common-false-positives
+
+      # Legacy preset is not recommended anymore
+      # More information: https://golangci-lint.run/usage/false-positives/#legacy
+      # - legacy
+
+      # std-error-handling is a set of rules that avoid reporting unhandled errors on common functions/methods
+      # More information: https://golangci-lint.run/usage/false-positives/#std-error-handling
+      - std-error-handling
+
   # some linters are enabled by default
   # https://golangci-lint.run/usage/linters/
   #
@@ -15,9 +45,6 @@ linters:
     # Errcheck is a program for checking for unchecked errors in Go code.
     - errcheck
 
-    # Linter for Go source code that specializes in simplifying code.
-    - gosimple
-
     # Vet examines Go source code and reports suspicious constructs.
     - govet
 
@@ -27,80 +54,107 @@ linters:
     # It's a set of rules from staticcheck. See https://staticcheck.io/
     - staticcheck
 
+    # Checks Go code for unused constants, variables, functions and types.
+    - unused
+
     # Fast, configurable, extensible, flexible, and beautiful linter for Go.
     # Drop-in replacement of golint.
     - revive
 
-linters-settings:
-  revive:
-    rules:
-      # these are the default revive rules
-      # you can remove the whole "rules" node if you want
-      # BUT
-      # ! /!\ they all need to be present when you want to add more rules than the default ones
-      # otherwise, you won't have the default rules, but only the ones you define in the "rules" node
+  settings:
+    revive:
+      rules:
+        # these are the default revive rules
+        # you can remove the whole "rules" node if you want
+        # BUT
+        # ! /!\ they all need to be present when you want to add more rules than the default ones
+        # otherwise, you won't have the default rules, but only the ones you define in the "rules" node
+
+        # Blank import should be only in a main or test package, or have a comment justifying it.
+        - name: blank-imports
+
+        # context.Context() should be the first parameter of a function when provided as argument.
+        - name: context-as-argument
+          arguments:
+            - allowTypesBefore: "*testing.T"
 
-      # Blank import should be only in a main or test package, or have a comment justifying it.
-      - name: blank-imports
+        # Basic types should not be used as a key in `context.WithValue`
+        - name: context-keys-type
 
-      # context.Context() should be the first parameter of a function when provided as argument.
-      - name: context-as-argument
-        arguments:
-          - allowTypesBefore: "*testing.T"
+        # Importing with `.` makes the programs much harder to understand
+        - name: dot-imports
 
-      # Basic types should not be used as a key in `context.WithValue`
-      - name: context-keys-type
+        # Empty blocks make code less readable and could be a symptom of a bug or unfinished refactoring.
+        - name: empty-block
 
-      # Importing with `.` makes the programs much harder to understand
-      - name: dot-imports
+        # for better readability, variables of type `error` must be named with the prefix `err`.
+        - name: error-naming
 
-      # Empty blocks make code less readable and could be a symptom of a bug or unfinished refactoring.
-      - name: empty-block
+        # for better readability, the errors should be last in the list of returned values by a function.
+        - name: error-return
 
-      # for better readability, variables of type `error` must be named with the prefix `err`.
-      - name: error-naming
+        # for better readability, error messages should not be capitalized or end with punctuation or a newline.
+        - name: error-strings
 
-      # for better readability, the errors should be last in the list of returned values by a function.
-      - name: error-return
+        # report when replacing `errors.New(fmt.Sprintf())` with `fmt.Errorf()` is possible
+        - name: errorf
 
-      # for better readability, error messages should not be capitalized or end with punctuation or a newline.
-      - name: error-strings
+        # check naming and commenting conventions on exported symbols.
+        - name: exported
+          arguments:
+            # make error messages clearer
+            - "sayRepetitiveInsteadOfStutters"
 
-      # report when replacing `errors.New(fmt.Sprintf())` with `fmt.Errorf()` is possible
-      - name: errorf
+        # incrementing an integer variable by 1 is recommended to be done using the `++` operator
+        - name: increment-decrement
 
-      # incrementing an integer variable by 1 is recommended to be done using the `++` operator
-      - name: increment-decrement
+        # highlights redundant else-blocks that can be eliminated from the code
+        - name: indent-error-flow
 
-      # highlights redundant else-blocks that can be eliminated from the code
-      - name: indent-error-flow
+        # This rule suggests a shorter way of writing ranges that do not use the second value.
+        - name: range
 
-      # This rule suggests a shorter way of writing ranges that do not use the second value.
-      - name: range
+        # receiver names in a method should reflect the struct name (p for Person, for example)
+        - name: receiver-naming
 
-      # receiver names in a method should reflect the struct name (p for Person, for example)
-      - name: receiver-naming
+        # redefining built in names (true, false, append, make) can lead to bugs very difficult to detect.
+        - name: redefines-builtin-id
 
-      # redefining built in names (true, false, append, make) can lead to bugs very difficult to detect.
-      - name: redefines-builtin-id
+        # redundant else-blocks that can be eliminated from the code.
+        - name: superfluous-else
 
-      # redundant else-blocks that can be eliminated from the code.
-      - name: superfluous-else
+        # prevent confusing name for variables when using `time` package
+        - name: time-naming
 
-      # prevent confusing name for variables when using `time` package
-      - name: time-naming
+        # warns when an exported function or method returns a value of an un-exported type.
+        - name: unexported-return
 
-      # warns when an exported function or method returns a value of an un-exported type.
-      - name: unexported-return
+        # spots and proposes to remove unreachable code. also helps to spot errors
+        - name: unreachable-code
 
-      # spots and proposes to remove unreachable code. also helps to spot errors
-      - name: unreachable-code
+        # Functions or methods with unused parameters can be a symptom of an unfinished refactoring or a bug.
+        - name: unused-parameter
 
-      # Functions or methods with unused parameters can be a symptom of an unfinished refactoring or a bug.
-      - name: unused-parameter
+        # report when a variable declaration can be simplified
+        - name: var-declaration
 
-      # report when a variable declaration can be simplified
-      - name: var-declaration
+        # warns when initialism, variable or package naming conventions are not followed.
+        - name: var-naming
 
-      # warns when initialism, variable or package naming conventions are not followed.
-      - name: var-naming
+output:
+  # Order to use when sorting results.
+  # Possible values: `file`, `linter`, and `severity`.
+  #
+  # If the severity values are inside the following list, they are ordered in this order:
+  #   1. error
+  #   2. warning
+  #   3. high
+  #   4. medium
+  #   5. low
+  # Either they are sorted alphabetically.
+  #
+  # Default: ["file"]
+  sort-order:
+    - linter
+    - severity
+    - file # filepath, line, and column.

02-basic/README.md

@@ -3,6 +3,7 @@
 See [.golangci.yml](.golangci.yml)
 
 It's [01-defaults](../01-defaults) plus :
+- [gofmt](#gofmt)
 - [revive](#revive)
 
 ## License
@@ -12,6 +13,10 @@ License: MIT
 golangci-lint configuration file made by @ccoVeille
 Source: https://github.com/ccoVeille/golangci-lint-config-examples/tree/main/02-basics
 
+## Enabled formatters
+### gofmt
+ format the code with Go standard library
+
 ## Enabled linters
 
 ### errcheck
@@ -33,6 +38,8 @@ Source: https://github.com/ccoVeille/golangci-lint-config-examples/tree/main/02-
  Fast, configurable, extensible, flexible, and beautiful linter for Go.
  Drop-in replacement of golint.
 
+These are the default ones available in revive
+
 #### blank-imports
 Blank import should be only in a main or test package, or have a comment justifying it.
 
@@ -60,6 +67,9 @@ for better readability, error messages should not be capitalized or end with pun
 #### errorf
 report when replacing `errors.New(fmt.Sprintf())` with `fmt.Errorf()` is possible
 
+#### exported
+check naming and commenting conventions on exported symbols.
+
 #### increment-decrement
 incrementing an integer variable by 1 is recommended to be done using the `++` operator