Add pre-commit hook to run config verify

[matthewhughes934]

Add this as a way to easily ensure configs stay valid. Filenames are not passed to the hook, this means For the default case (config in one of the default searched files), the config is picked up automatically and there's nothing extra to configure. For the case of a non-standard config setup the hook can be configured like

repos:
-   repo: https://github.com/golangci/golangci-lint
    rev: v1.57.2
    hooks:
    -   id: golangci-lint-config-verify
        # config is kept at '.golangci-config.yaml'
        files: \.golangci-config\.yaml
        args: ['--config', '.golangci-config.yaml']

[boring-cyborg]

Hey, thank you for opening your first Pull Request !

[CLAassistant]

All committers have signed the CLA.

[matthewhughes934]

I skipped submitting a feature request issue since it seemed as simple to just discuss the change itself

[ldez]

The validation of the configuration against the JSON Schema is different than using run.
The deprecated options are removed from the JSON Schema (draft-07 doesn't have deprecation support).
The run command (and only the run command) displays deprecation messages, but the validation will display that the properties are missing and will lead to this kind of misunderstanding: #4593

Also, I don't see the point in systematically checking a configuration which most of the time has not changed.
IDEs and text editors allow us to do that live, a call to a pre-commit hook seems overkill.

I'm not a pre-commit user, by choice, maybe there is an interest in this validation hook that I don't see, and I will be happy to learn about it.

[matthewhughes934]

Also, I don't see the point in systematically checking a configuration which most of the time has not changed.

This hook will only be executed via pre-commit run if there's a change in one of the files matching the pattern in files, so it should only check the config if something has changed (though in CI I expect most people to run with pre-commit run --all-files in which case it will always check, but that's just a small bit of extra time in CI which I think is reasonable)

The deprecated options are removed from the JSON Schema (draft-07 doesn't have deprecation support).
The run command (and only the run command) displays deprecation messages, but the validation will display that the properties are missing and will lead to this kind of misunderstanding: #4593

My use case is: I just want to keep my config up-to-date: if a change brings deprecates some option I'm using then I want to be aware of if (and remove it) as soon as I can. This could probably also be solved by just running golangci-lint config verify in CI, but I like the workflow of working with pre-commit

I have no opinion re: potential misunderstandings, if you think this has the potential to be a bother then I have no objections

IDEs and text editors allow us to do that live, a call to a pre-commit hook seems overkill.

This would require everyone working in a project to have their (potentially various) IDEs/editors configured to handle this, vs. just having everyone install pre-commit and have it managed there (unless I misunderstood, in my workflows I tend to prefer tools over trying to support different editors etc. so I'm not familiar with that approach).

[ldez]

I have no opinion re: potential misunderstandings, if you think this has the potential to be a bother then I have no objections

It's not a blocker, it's more a warning, if there are too many issues on the topic, we will see how to handle that.

This would require everyone working in a project to have their (potentially various) IDEs/editors configured to handle this,

At least for the IDEs I use, there is no configuration required, no specific user action or installation, it's just handled automatically based on the file name.

The configuration file names are defined inside the schema store: https://github.com/SchemaStore/schemastore/blob/c42ad08e78f70a0d37f6fb53a204371ef80bc3d4/src/api/json/catalog.json#L2139-L2143

But I'm not a pre-commit user, and your workflow seems right for a pre-commit user.

[ldez]

LGTM

[matthewhughes934]

It's not a blocker, it's more a warning, if there are too many issues on the topic, we will see how to handle that.

👍 I'd be happy to be pinged/included if any such issues do arise