[json] Support json-schema draft 2020-12

Question

[json] Support json-schema draft 2020-12

stephprobst opened this issue 2 years ago · 7 comments

Type: Bug

When using json-schema draft 2020-12 in VS Code the code completion no longer works anywhere except for the root level of the json object.

Steps to reproduce:

Open VS Code and create a new text file
Enter the following code snippet:

{
    "$schema": "http://json-schema.org/draft/2020-12/schema",
    "properties": {
        "test": {
            "type": "string"
        }
    }
}

Try code completions for the keywords 'properties' and 'type'. The code completion works for the 'properties' keyword, but it does not work for the 'type' keyword.

Expected behaviour:
The code completion should work everywhere in the document.

Screenshots:

System information:

VS Code version: Code 1.72.2 (d045a5e, 2022-10-12T22:15:18.074Z)
OS version: Windows_NT x64 10.0.19044
Modes:
Sandboxed: No

System Info

Item	Value
CPUs	11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz (8 x 2803)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	undefined
Memory (System)	31.73GB (23.11GB free)
Process Argv	--crash-reporter-id 3f7fdc24-37cc-44a0-a7f9-36f08a086dab
Screen Reader	no
VM	0%

Extensions (15)

Extension	Author (truncated)	Version
simple-react-snippets	bur	1.2.7
path-intellisense	chr	2.8.1
vscode-eslint	dba	2.2.6
prettier-vscode	esb	9.9.0
solidity	Jua	0.0.141
python	ms-	2022.16.1
vscode-pylance	ms-	2022.11.10
jupyter	ms-	2022.9.1202862440
jupyter-keymap	ms-	1.0.0
jupyter-renderers	ms-	1.0.10
vscode-jupyter-cell-tags	ms-	0.1.6
vscode-jupyter-slideshow	ms-	0.1.5
vscode-open	san	0.1.0
vscode-icons	vsc	12.0.1
markdown-all-in-one	yzh	3.4.3

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vsclangdc:30486549
c4g48928:30535728
dsvsc012:30540252
azure-dev_surveyone:30548225
pyindex848:30577860
nodejswelcome1:30587005
fc301958:30595537
2e4cg342:30596373

Answer 1 · 2022-11-02T07:19:07.000Z

@aeschli New issue has been created as requested in #98724.

Answer 2 · 2022-11-03T16:46:54.000Z

Looking at the content of the schema, most schema rules are extracted into different files listed in "$vocabulary", which we unfortunately don't understand.

Answer 3 · 2023-08-06T23:04:11.000Z

most schema rules are extracted into different files listed in "$vocabulary", which we unfortunately don't understand.

Happy to answer any questions...

Answer 4 · 2023-08-25T14:44:06.000Z

This would be extremely useful to have for schema authors. It doesn't affect users of schemas as much, but it's very impactful for schema authors.

If you're defining a new schema or meta-schema it's frustrating and, more importantly, error-prone to lose validation and IntelliSense when you move into any object-value keyword from the top-level.

The support that 2020-12 lays down for defining schema dialects is wildly useful for schema authors, but hand-crafting those definitions in VS Code means constantly moving from the editor to a CLI tool to validate the schema. Nearly all of the author-time development experience is lost.

An example of a useful schema dialect is actually for defining a schema that uses VS Code's own annotation keywords:

{
	// Spec keywords
	
	// VSCode extensions

	defaultSnippets?: { label?: string; description?: string; markdownDescription?: string; body?: any; bodyText?: string; }[]; // VSCode extension: body: a object that will be converted to a JSON string. bodyText: text with \t and \n
	errorMessage?: string; // VSCode extension
	patternErrorMessage?: string; // VSCode extension
	deprecationMessage?: string; // VSCode extension
	enumDescriptions?: string[]; // VSCode extension
	markdownEnumDescriptions?: string[]; // VSCode extension
	markdownDescription?: string; // VSCode extension
	doNotSuggest?: boolean; // VSCode extension
	suggestSortText?: string;  // VSCode extension
	allowComments?: boolean; // VSCode extension
	allowTrailingCommas?: boolean; // VSCode extension
}

Having schema dialects for people authoring a schema who want to have the best possible UX for folks filling out a document adhering to that schema would be great.

I work on a lot of side projects that involve writing schemas for configuration files and documenting configurations. While I could pin those schemas to using draft 7, it's more maintainable for me to use 2020-12, especially when you consider annotations like versioning information or the link to online docs:

{
  "title": "Cache Busters",
  "description": "Defines a list of sources and targets to re-process assets for supporting Tailwind's JIT compiler.",
  "markdownDescription": "...", // longer block with pretty-rendering info
  "minimumVersion": "0.112.0",
  "docsUrl": "https://gohugo.io/getting-started/configuration/#configure-cache-busters",
  "type": "array",
  "uniqueItems": true,
  "items": {
    // definition for a cache buster
  }
}

I don't think I'd be very helpful for implementing 2020-12 support, but I'd be happy to test things out and to help with the documentation.

VS Code's support for using JSON schemas is wildly good. Being able to get IntelliSense, high-quality validation error messages, and contextual documentation makes filling out schematized documents in VS Code so much easier than keeping the reference to the schema open and re-running a validator every few minutes.

I'd love to see VS Code's support for authoring schemas match that experience, and 2020-12 support, which makes authoring new vocabulary so much easier, is a huge part of that.

Answer 5 · 2023-08-27T20:37:34.000Z

@michaeltlombardi thanks for adding in your use case. It's very enlightening.

Regarding custom dilect support, it's important to remember that any implementation (whether its a validator or an editor or something else) can only support vocabularies that it's been programmed to understand. There's nothing yet defined that provides a machine-readable format that allows implementations to automatically understand new vocabularies.

That said, we (the JSON Schema team) are working on defining that. Until then $vocabulary is still very much a work in progress.

Answer 6 · 2023-08-28T19:17:46.000Z

@gregsdennis yup! For right now, I've only been defining/using annotation keywords, even though I keep finding useful ideas for other keywords.

Answer 7 · 2024-03-25T11:38:42.000Z

@aeschli

Looking at the content of the schema, most schema rules are extracted into different files listed in "$vocabulary", which we unfortunately don't understand.

Is it still the case today? The site has the section on bundling schemas, which relies on different "$id" resolution mechanics onwards from draft/2019-09. If multi-file nature of meta-schemas is the problem, so maybe it's worth to bundle it and incrementally make a basic implementation against it, ignoring all the super-duper dynamic free-for-all logic for now.