Add JSON schema file for configuration file

[bartlomieju]

Currently Deno supports configuration file for altering TypeScript compiler settings. With #11686 and #11857 we'll have more configuration options and config file will be usable with deno lint and deno fmt.

The idea is to make the configuration file strict - ie. it will not accept "unknown" fields (it will fail the parsing step if there are extraneous fields). This is to avoid the problem similar to package.json where random tools piggy-back on this file and add tens (or hundreds) of fields specific to each tool.

To alleviate the problem we should introduce a JSON schema file. Most IDEs already support this format and it's used widely in the wild, eg. here's TypeScript JSON schema and here's dprint JSON schema. Additional advantage is that these schema files are versioned, which should help with making sure Deno's configuration file does not introduce breaking changes.

[dsherret]

$schema Property is VSCode Specific

For associating a config file something that is done is a $schema property that specifies a url:

deno/.dprint.json

Line 2 in b518f5e

"$schema": "https://dprint.dev/schemas/v0.json",

However, I would recommend against this because:

1. It is actually a VSCode specific property.
2. It is something the user needs to manually maintain.

I am going to be moving away from this in dprint soon towards something better.

Better Solution?

Instead I would recommend we come up with a solution where the deno binary can provide either the entire schema text or a url to the schema (for example, we could have the schema as a release artifact). Probably providing a url would be best as it will most likely be portable. For example, perhaps the deno language server could provide the JSON schema url at startup then it would be up to the editors to associate that schema with Deno.json.

For vscode specifically, we can provide the schema programatically in vscode-deno based on the version of deno the user is using with the extension (was just coincidentally told about this today while doing research for dprint microsoft/vscode#127812).

Maybe there is a better way of doing all this with the LSP to do this though so all editors get the schema associated out of the box? I don't see a way of doing it, but I'm not super familiar with the LSP. cc @kitsonk

[bartlomieju]

Thanks for clearing that up David, I could have sworn I used JSON schema in JetBrains IDEs as well.

I'm curious to see Kitson's opinion before we decide either way.

[kitsonk]

You can associate files with a schema without using the $schema property. For example that is how we support suggestions/checking for import maps in vscode_deno. So we can associate a schema with Deno.json.

We have a JSON schema for the output of deno info --json that is located in the manual. We should have a schema for everything. I have started one for deno doc --json that will be part of deno_doc.

[jthegedus]

Thanks for clearing that up David, I could have sworn I used JSON schema in JetBrains IDEs as well.

JetBrains IDEs ship a default plugin to fetch JSON schemas from
http://www.schemastore.org/json/

VSCode handles this type of association on a per VSCode Extension basis. I believe the VSCode RedHat YAML ext is trying to be a catch all for users. I'm unaware of how VSCode handles conflicts but I often see issues with my GitHub Workflow schemas being incorrectly associated with other schemas.

Best bet is to pick either adding to schemastore or handling schema in the Deno LSP/Ext, but not both.