Register JSON Schemas with schemastore.org

[aaronsteers]

Thanks so much for creating these! Have you considered registering these with https://schemastore.org?

At Meltano, we registered our JSON schema in schemastore.org - which is then automatically applied in VS Code and other IDEs that subscribe to the schemastore.org manifests (listed at https://www.schemastore.org/json/#editors).

Our PR is here as an example: https://github.com/SchemaStore/schemastore/pull/2020

Within a few hours of the PR being merged, VS Code users will start getting auto-complete and underline-linting automatically with no local config required. 🚀 (The only requirement, I think, is that they have the Yaml extension installed.)

[joellabes]

It's definitely in the cards! See #3 - because we have multiple schema files, to make them play nicely together they'd have to be uploaded into the schemastore repo instead of just referencing the GitHub hotlink, but that has negative tradeoffs too.

(Of course without #4 the "playing nice together" is purely hypothetical)

[gwenwindflower]

i want to bump this issue now that we have the latest schema definition set up, we should be able to tackle this right?

feels like we should get it on the roadmap.

[joellabes]

Agreed! The one thing that has been holding me back is that there is nothing about a dbt project's whatever.yml files that identifies them as dbt files, which means we would need to lay claim to the entire **.yml glob and I don't think the schemastore folks would like that.

I guess we could assume that everyone's directories follow the defaults and claim [**/models/**.yml, **/seeds/**.yml, **/snapshots/**.yml] and so on as a solid guess.

[gwenwindflower]

i like it, i think that's solid, while i think people definitely get creative with how they organize yaml files within those directories, i doubt too many people deviate from that.

[will-sargent-dbtlabs]

Hi yall, jumping on the thread here... If we assume the defaults (in favor of), is it possible for folks on the VSC side to manually add additional directories to assume the files are ours if the need too?

If so, then it feels like covering the 80% or better is a low-friction choice, that still leaves the options open for those that have non-standard top-level folders.., who had to do some custom config anyway.

If memory serves, that config can be version controlled as well in the repo, so it's a one-time setup per project for these complex scenarios..

[joellabes]

Yes that’s correct! They can either continue to configure manually in .vscode/settings.json or associate it through the VS Code UI