Version the config schemas so that users can specify version in their config file for automatic IDE schema validations

[dakojohn]

Welcome

• Yes, I've searched similar issues on GitHub and didn't find any.
• I agree to follow this project's Code of Conduct

Your feature request related to a problem? Please describe

Dependency updating takes time on large teams, especially if it's not currently broken.

IDEs automatically use the config schema that was recently created to provide schema validation in the editor, but because the only schema available is for the current version of golangci-lint, the validation in IDEs may not reflect the version a user is running, causing confusion.

Describe the solution you'd like

Find a way to version the schemas you are hosting so that users that are on an older version of golangci-lint can select the correct version of the schema, and are not confused by the IDEs automatic schema validation.

Describe alternatives you've considered

Not really any viable alternatives... I guess I could disable schema validation in my IDE for every repo I touch with golangci-lint? But that defeats the purpose of schema validation.

Additional context

No response

Supporter

• I am a sponsor through GitHub or OpenCollective

[boring-cyborg]

Hey, thank you for opening your first Issue ! 🙂 If you would like to contribute we have a guide for contributors.

[ldez]

Hello,

the JSON Schema is already versioned:

• https://golangci-lint.run/jsonschema/golangci.jsonschema.json
• https://golangci-lint.run/jsonschema/golangci.v1.59.jsonschema.json
• https://golangci-lint.run/jsonschema/golangci.v1.58.jsonschema.json

[dakojohn]

That was not clear from the documentation or from the url. With this, I can at least put a comment directive in the file to direct my IDE to an older schema.

Currently the schema store entry links to the most recent schema only. In the Contributing doc in schema store's github, in the section about hosting your own schema, they link to the an example PR. Following any of the url links in this example (like the first one for ORY Hydra) to their self hosted schema, they are using a combination of oneOf and allOf to switch the schema validations off of a version field. I was expecting something more akin to this solution, which would be more automatic for users of golangci-lint.

[ldez]

We only maintain one version of golangci-lint (the latest), and the current versioned schemas are just a convenience for the CLI command golangci-lint config verify.

Based on the fact we only maintain one version of golangci-lint, I don't think creating an extra step to handle multiple versions of the schema is worth the cost.

Also, the multi-version hydra schema works only because the configuration of hydra contains a field version.
We don't plan to add this type of field inside the golangci-lint configuration.

I highly discourage the usage of other versions than the "latest" stable version of golangci-lint.

[dakojohn]

The teams I'm on make use of a large number of the linters available in golangci-lint. A while back, we were keeping up with bleeding edge, but were required to pin the version we were using after repeated breaking changes to linter config options started blocking feature development. We now review and update the version we use every ~6 months, in line with established team policy. This kind of problem and solution are not unusual in larger enterprise environments.

While I understand, and respect, that you only really support the most recent version, the recent addition of the schema validation that IDEs automatically implement has caused teammates to put up PRs with bad linter config changes because the current version of the schema is different from the version we are using.

I am not proposing a change to your supported versions, only proposing schema version awareness for IDE schema validation purposes.

[ldez]

I am not proposing a change to your supported versions, only proposing schema version awareness for IDE schema validation purposes.

To have schema version awareness we should have a version inside the configuration, and as I explained we don't plan to do that for now.
A version inside the configuration implies several topics, not only JSON schema.

the recent addition of the schema validation that IDEs automatically implement

The JSON schema is not new: before it was inside the schema store repository and it was already used by IDE.

This schema was not created by golangci-lint maintainers, it was difficult to maintain, so we moved the schema from the schema store to our repo and created a schema by version.

This kind of problem and solution are not unusual in larger enterprise environments.

Larger enterprises don't seem to care a lot about golangci-lint sustainability.
The total amount of money that golangci-lint gets monthly from funding/sponsoring is $2 (to be precise $1.80), if you want to check that https://opencollective.com/golangci-lint.

It requires a lot of work and time to maintain golangci-lint, I think we can say that golangci-lint is enterprise-grade software, at least we try to create high-quality software and documentation.

So we have to use our time as best as we can.
It's not against you, it's just pragmatic.

Rule n°1 of open-source: no is temporary, yes is forever.

So I don't say we will never create multi-version JSON schema, but for now, it's easier for us to just provide a simple link to JSON schema by version.