-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
feat: new fmt
command with dedicated formatter configuration
#5357
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
I think making this still supported as a linter and available with the --fix
flag is a great suggestion.
Have you done any testing on performance? I'd imagine golangci-lint fmt
on big codebases would potentially be faster than golangci-lint run --fix
or are they the same? When would you suggest one over the other? On save in your editor?
Yes, I did it. The
The 2 commands have different goals, I cannot suggest one over the other. But I suggest always running |
I will not merge this PR for now: based on Go release cycle, go1.24 will be released in 2 weeks. I want to keep this feature for v2 and I want the last v1 release to support go1.24. Also, for now, I don't want to play with a dedicated This is frustrating for me because I want to see this new command used and I have another PR ready based on the branch of this PR. |
3622326
to
1d8c9c1
Compare
Important
This PR deliberately omits documentation about the new options and section (but the JSONSchema is updated).
This is because I don't want to deprecate the previous elements for now: I think it is better to handle that when all the v2 proposals are managed to avoid multiple migrations.
The command
golangci-lint fmt
formats the code by default.The current default is the same format used by
go fmt
(!=gofmt
).There is no support for stdin.
The formatters defined in the
formatters.enable
are added automatically tolinters.enable
.If a formatter is enabled inside
formatters
andlinters
, the configuration offormatters.settings
will overridelinters-settings
even if the configuration is omitted or empty insideformatters.settings
section.This means the formatter activation and configurations should be defined only on the
formatters
orlinters
+linters-settings
section and not mixed.The exclusions from
formatters.exclusions[].paths
are converted tolinters.exclusions[].rules
automatically.There are only 3(4) flags:
Note, that the
-E, --enable
flags work like--enable-only
for linters: it overrides the formatters defined inside the configuration file.It is the opposite of the behavior of the
-E, --enable
flags of therun
command where this flag always adds linters to those defined inside the configuration file.In v2, the configuration of formatters will not be allowed inside the
linters-settings
section.Fixes #5296