Hey, thank you for opening your first Pull Request !

In order for a pull request adding a linter to be reviewed, the linter and the PR must follow some requirements.

• The CLA must be signed

Pull Request Description

• It must have a link to the linter repository.
• It must provide a short description of the linter.

Linter

• It must not be a duplicate of another linter or a rule of a linter (the team will help to verify that).
• It must have a valid license (AGPL is not allowed), and the file must contain the required information by the license, ex: author, year, etc.
• It must use Go version <= 1.23.0
• The linter repository must have a CI and tests.
• It must usego/analysis.
• It must have a valid semver tag, ex:v1.0.0,v0.1.0 (0.0.x are not valid).
• It must not containinit().
• It must not containpanic().
• It must not containlog.Fatal(),os.Exit(), or similar.
• It must not modify the AST.
• It must not have false positives/negatives (the team will help to verify that).
• It must have tests inside golangci-lint.

The Linter Tests Inside Golangci-lint

• They must have at least one std lib import.
• They must have integration tests without configuration (default).
• They must have integration tests with configuration (if the linter has a configuration).

.golangci.next.reference.yml

• The file.golangci.next.reference.yml must be updated.
• The file.golangci.reference.yml must NOT be edited.
• The linter must be added to the lists of available linters (alphabetical case-insensitive order).
  • enable anddisable options
• If the linter has a configuration, the exhaustive configuration of the linter must be added (alphabetical case-insensitive order)
  • The values must be different from the default ones.
  • The default values must be defined in a comment.
  • The option must have a short description.

Others Requirements

• The files (tests and linter) inside golangci-lint must have the same name as the linter.
• The.golangci.yml of golangci-lint itself must not be edited and the linter must not be added to this file.
• The linters must be sorted in the alphabetical order (case-insensitive) in thelintersdb/builder_linter.go and.golangci.next.reference.yml.
• The load mode (WithLoadMode(...)):
  • if the linter usesgoanalysis.LoadModeSyntax -> noWithLoadForGoAnalysis() inlintersdb/builder_linter.go
  • if the linter usesgoanalysis.LoadModeTypesInfo, it requiresWithLoadForGoAnalysis() inlintersdb/builder_linter.go
• The version inWithSince(...) must be the next minor version (v2.X.0) of golangci-lint.
• WithURL() must contain the URL of the repository.

Recommendations

• The filejsonschema/golangci.next.jsonschema.json should be updated.
• The filejsonschema/golangci.jsonschema.json must NOT be edited.
• The linter repository should have a readme and linting.
• The linter should be published as a binary (useful for diagnosing bug origins).
• The linter repository should have a.gitignore (IDE files, binaries, OS files, etc. should not be committed)
• A tag should never be recreated.
• usemain as the default branch name.

The golangci-lint team will edit this comment to check the boxes before and during the review.

The code review will start after the completion of those checkboxes (except for the specific items that the team will help to verify).

The reviews should be addressed as commits (no squash).

If the author of the PR is a member of the golangci-lint team, he should not edit this message.

This checklist does not imply that we will accept the linter.

I think it could be a part ofgomoddirectives as the goal is to organizerequire directives.

🤔 maybe this should be a formatter instead of a linter

Hi@ldez
Thanks for your time to analyze this PR and for your rapid response.
I have been thinking on both of your comments and I think them both are good approaches.

Includinggomodclean intogomoddirectives makes sense, since both projects analyzes thego.mod file (the use of the directives included into thego.mod file). This project started when I saw somego.mod files that had gone terribly wild, so I decided to create a simple linter. I had the goal to do something simple, something that only did one thing, but did it well. If we include this functionality intogomoddirectives, its complexity would grow (since it already contains many rules for different directives and configuration and I am thinking about adding an autofix option). I believe it would be more complex to keep scalinggomodclean independently.
On the other hand, your idea about converting it into a formatter instead of a linter sounds pretty good. I could change the name togomodfmt. This approach gives us the possibility to keepgomodfmtgrowing and add some functionalities that wouldn't fit well intogomoddirectives (maybe because of the purpose ofgomoddirectives or the extra complexity). My goal for the future is to keep mainteinance, add the autofix mode and, at that moment, consider a finished version and release the v1.0.0 version.

Anyway, both options fit well for me.
Looking forward to your response and your thoughts about it.

Thank you again!!