Add swaggo/swag formatter

[cooperbenson-qz]

Adding the comment formatter from swaggo/swag

[boring-cyborg]

Hey, thank you for opening your first Pull Request !

[CLAassistant]

All committers have signed the CLA.

[ldez]

In order for a pull request adding a formatter 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 formatter repository.
• A short description of the formatter must be provided.

Formatter

• It must not be a duplicate of another linter/formatter or a rule of a linter/formatter (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.22
• The linter repository must have a CI and tests.
• It must be a real formatter.
• It must have a valid tag, ex: v1.0.0, v0.1.0.
• It must not contain init().
• It must not contain panic().
• It must not contain log.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 Formatter 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 formatters (alphabetical case-insensitive order).
  • enable option
• If the formatter has a configuration, the exhaustive configuration of the formatter 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 the lintersdb/builder_linter.go and .golangci.next.reference.yml.
• The load mode (WithLoadMode(...)) must be goanalysis.LoadModeSyntax -> no WithLoadForGoAnalysis() in lintersdb/builder_linter.go
• The version in WithSince(...) must be the next minor version (v2.X.0) of golangci-lint.
• WithURL() must contain the URL of the repository.

Recommendations

• The file jsonschema/golangci.next.jsonschema.json should be updated.
• The file jsonschema/golangci.jsonschema.json must NOT be edited.
• The formatter repository should have a readme and linting.
• The formatter should be published as a binary (useful for diagnosing bug origins).
• The formatter repository should have a .gitignore (IDE files, binaries, OS files, etc. should not be committed)
• A tag should never be recreated.
• use main 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 formatter.

[ldez]

🤔 The formatter is not isolated into a module, so there are unrelated dependencies.

I'm not sure I want to integrate this formatter in this way.

Also, there is dead code inside the formatter itself.

[cooperbenson-qz]

That's all fair. I was trying to integrate an existing formatter for my own use, but that means I don't really have much control over it. I could try to raise an issue or PR on the base repo but I'm uncertain how much work it would take to adress the above issues

[ldez]

And it's related to Swagger 2.0 and not OpenAPI 3 (2017)

[ldez]

I don't really have much control over it.

I have a solution, but before applying it, I want to evaluate the value of this formatter.

If it's too niche and old, it can become a problem quickly.

[ldez]

I found this:

• 2020: Swagger 2.0 (43.9%), OpenAPI 3.0 (27.8%) report
• 2021: Swagger 2.0 (54%) and OpenAPI 3.0 (40%) report
• 2022: Swagger 2.0 (55%) and OpenAPI 3.x (39%) report
• 2023: No exact data but Swagger 2.0 > OpenAPI 3.x report
• 2024: No data report

[ldez]

And based on https://github.com/swaggo/swag/releases/tag/v2.0.0-rc4, OpenAPI V3 will be supported.

[ldez]

swaggo/swag seems popular:

• https://github.com/swaggo/swag/network/dependents?package_id=UGFja2FnZS0yMjY0ODMzMDEz
• 11.6 k stars

The project seems active.
The support of OpenAPI v3 is on the way.

I don't think that isolating the formatter inside a module will be something valuable for the swaggo team:

• Submodules are a pain to manage.
• The formatter depends on non-exposed constants defined inside parser.go

So, the best approach for me is to create a hard fork with only the useful files (the fork will be created inside the golangci organization).

I think it can be a good idea to open an issue on the swaggo/swag repository to inform the team of this fork.