Add the config schema to schemastore.org

[zepatrik]

Is your feature request related to a problem? Please describe.

schemastore.org provides json schemas via an API for editors like VSCode and JetBrains to offer code completion, validation and more. If we add our config.schema.json our users get editor support for config files.

Describe the solution you'd like

We can easily submit a PR to add our schema. One problem I see is that the config file per default is called config.yml which is not descriptive enough. We should rather change the default file name to be kratos.yml so we can add the pattern.

Describe alternatives you've considered

Add the schema but keep the default config.yml. This would result in most of the users not benefiting from the feature as they probably use the default file name.

Additional context

It is important to figure out how they do versioning of schemas, especially for us as it changes quite often.

[zepatrik]

The versioning strategy of schemastore.org is to just postfix the file with the version number and load the burden of deciding which version to use to the editor (e.g. by examining the environment). As this will clearly not work with our config files my proposal is to add a top level version key that currently only is used for validation. Kratos will use a config file although the version does not match but spit out a warning. This key will be required then. Further we can write a "version meta" schema that uses oneOf/allOf directives to map the top level version key to the proper schema hosted on github. We can even automate the generation of that file when releasing 🎉

[tacurran]

@zepatrik
JSON schema maps the structure of JSON files, so assume that the version meta is a JSON schema. Regarding the "add a top level version key that currently only is used for validation" Would you suggest (e.g. version meta - a JSON containing all versions and descriptions thereof) using a JSON Schema ($schema": "http://json.schemastore.org/kratosconfig) to describe the version and the use $ref to navigate to the actual schema.

In a JSON schema, a $ref keyword is a JSON Pointer to a schema, or a type or property in a schema. A JSON pointer takes the form of A # B in which: A is the relative path from the current schema to a target schema. ... B is the complete path from the root of the schema to a type or property in the schema. (http://niem.github.io/json/reference/json-schema/references/)
"Further we can write a "version meta" schema that uses oneOf/allOf directives to map the top level version key to the proper schema hosted on github." This would have to be either in the ory/kratos/ release config since schemastore.org does not seem to accept the type of "version meta" you imagine.

In addition, schemas may be combined with the following keywords:
allOf: must be valid against all of the subschemas
anyOf: must be valid against any of the subschemas
oneOf: must be valid against exactly one of the subschemas

It would then work similar to https://json.schemastore.org/circleciconfig

There is also a relative pointers under discussion in ietf (https://datatracker.ietf.org/doc/draft-handrews-relative-json-pointer/)

Regarding the question of adding this to IDE, in VS CODE there are several possibilities. See the following
https://code.visualstudio.com/docs/languages/json

Mapping in the JSON#
In the following example, the JSON file specifies that its contents follow the CoffeeLint schema.

{
"$schema": "http://json.schemastore.org/coffeelint",
"line_endings": "unix"
}
Note that this syntax is VS Code-specific and not part of the JSON Schema specification. Adding the $schema key changes the JSON itself, which systems consuming the JSON might not expect, for example, schema validation might fail. If this is the case, you can use one of the other mapping methods