Update JSON Schema on schemastore.org

[reitzig]

🔧 Summary

The JSON Schema published on schemastore.org is out of date.

(re #288, cc @hyperupcall )

Lefthook version

1.6.1

Steps to reproduce

Create a config like this:

pre-commit:
  piped: true
  commands:
    formatter:
      priority: 1
      glob: "*.go"
      run: go fmt ./...
      stage_fixed: true
    vet:
      priority: 1
      glob: "*.go"
      run: for f in {staged_files}; do go vet "${f}"; done

Expected results

No schema violations

Actual results

*.commands.*.priority not supported:

There may be more mismatches for any features added and changes made since SchemaStore/schemastore@c4b2db5d; this is just the one I ran into.

Possible Solution

• Update the schema to the current state.
• Source the schema in this repository and include tests against it in the build; re-submit to schemastore on releases.
  • Would the schema need versioning?

[hyperupcall]

In SchemaStore/schemastore#3591, I updated the schema to include the latest additions to the config file. Since schemas in schemastore aren't (usually) maintained by project maintainers but rather schemastore people involved with schemastore, it is probably better to open an issue there.

[reitzig]

Thank you!

Since schemas in schemastore aren't maintained by project maintainers but rather schemastore

How curious! Is there no way for a project to maintain their own schemas? Where can I read up on that?

[hyperupcall]

How curious! Is there no way for a project to maintain their own schemas? Where can I read up on that?

@reitzig I appear to have mispoken. What I meant, simply, is that when a schema is located in the schemastore repository, it is better to file an issue in the schemastore repository. I said what I said because typically, for the project maintainers that do add schemas or make fixes to schemas that are hosted in schemastore, it's usually not something that happens every release or update - other contributors fill in the gaps. I personally don't expect project maintainers to do this updating, that is why the schemas are in SchemaStore. And the other reason, for some schemas, the contributions are made from only non-project maintainers, which is why raising the issue in schemastore would be more relevant. But this isn't always the case and there many examples where this isn't the case.

To answer your question: there are two places where projects can maintain their schema: either in schemastore, or in the project repository itself.

If the schemas are located in schemastore, the testing infrastructure is already setup, merging fixes is typically faster (me and the primary owner typically merge within a few hours to a few days, depending on PR complexity and schedule), and we also use a GitHub action to allow maintainers to merge fixes themselves, reading from CODEOWNERS file (so yes, a project can maintain their own schemas within SchemaStore).

If the schemas are located in the project repository itself, then naturally the project has more control over the schema. The pattern I've observed is that people sometimes people choose this if the schema is automatically generated by a command or, usually if the schema is used by a proprietary tool. There are plenty of exceptions, of course.

There is a tradeoff, and we give the ability for project maintainers to choose what they'd like. For more information, we have a CONTRIBUTING.md and if you have questions that aren't answered by that I'd be happy to answer them