[json] support references in schema associations

[johnnaylor]

Issue Type: Bug

Steps to repro

in settings.json...

"json.schemas": [

        {
            "url": "http://localhost:8080/my.schema.json#/$defs/inner_schema",
            "fileMatch": [
                "/**/tests/testfile.json"
            ]
        }
]

in ./tests/testfile.json

{
    "name": "example"
}

in ./schemata/my.schema.json

{
    "$schema": "https://json-schema.org/draft-07/schema#",
    "$id": "https://example.com/schemata/my.schema.json#",
    "type": "boolean",
    "default": true,
    "$defs": {
        "inner_schema": {
            "type": "object",
            "properties": {
                "name": {
                    "type": "string"
                }
            },
            "additionalProperties": false
        }
    }
}

in root folder package.json I'm using a simple web server to serve the local schemas.

{
  "dependencies": {
    "http-server": "^13.0.1"
  },
  "scripts": {
    "dev": "http-server ./schemata -p 8080",
    "start": "npm run dev&"
  }
}

To serve the files in ./schemata locally...

$ npm start

Disable/Enable the JSON>Format setting to force the schema to be pulled.

Incorrect Behaviour in Latest Version

Version: 1.63.2 Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3 Date: 2021-12-15T09:37:28.172Z (5 days ago) Electron: 13.5.2 Chromium: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0

1. change the "name" property to something else. Observe that intellisense DOES NOT flag an error.

Logging from http-server

[2021-12-20T21:14:41.762Z] "GET /my.schema.json" "undefined" (node:16871) [DEP0066] DeprecationWarning: OutgoingMessage.prototype._headers is deprecated (Use node --trace-deprecation ... to show where the warning was created) [2021-12-20T21:14:42.083Z] "GET /my.schema.json" "undefined"

Correct Behaviour in October Version

Version: 1.62.3 Commit: ccbaa2d27e38e5afa3e5c21c1c7bef4657064247 Date: 2021-11-17T07:59:13.865Z (1 mo ago) Electron: 13.5.2 Chrome: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0

1. change the "name" property to something else (I deleted the a). Observe that intellisense DOES flag an error "Property nme is not allowed" and squiggle underlines the property.

Logging from http-server

[2021-12-20T21:08:14.282Z] "GET /my.schema.json" "undefined" (node:16271) [DEP0066] DeprecationWarning: OutgoingMessage.prototype._headers is deprecated (Use node --trace-deprecation ... to show where the warning was created) [2021-12-20T21:08:14.699Z] "GET /my.schema.json" "undefined"

VS Code version: Code 1.63.2 (899d46d82c4c95423fb7e10e68eba52050e30ba3, 2021-12-15T09:37:28.172Z) OS version: Darwin x64 20.6.0 Restricted Mode: No

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz (16 x 2300)| |GPU Status|2d_canvas: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
webgl: enabled
webgl2: enabled| |Load (avg)|2, 3, 3| |Memory (System)|16.00GB (0.02GB free)| |Process Argv|--crash-reporter-id 2ef050c8-e5c1-40dc-bd2f-e23017bbfd9e| |Screen Reader|no| |VM|0%|

Extensions (16)

Extension|Author (truncated)|Version ---|---|--- vscode-openapi|42C|4.7.1 doxdocgen|csc|1.3.2 vscode-pull-request-github|Git|0.34.1 better-cpp-syntax|jef|1.15.10 remote-containers|ms-|0.209.6 remote-ssh|ms-|0.70.0 remote-ssh-edit|ms-|0.70.0 remote-wsl|ms-|0.63.13 cmake-tools|ms-|1.9.2 cpptools|ms-|1.7.1 cpptools-extension-pack|ms-|1.1.0 vsliveshare|ms-|1.0.5200 vsliveshare-audio|ms-|0.1.91 vscode-yaml|red|1.2.2 cmake|twx|0.0.17 debug|web|0.25.1 (1 theme extensions excluded)

A/B Experiments

``` vsliv368cf:30146710 vsreu685:30147344 python383cf:30185419 vspor879:30202332 vspor708:30202333 vspor363:30204092 pythontb:30283811 pythonptprofiler:30281270 vshan820:30294714 vstes263:30335439 vscoreces:30384385 pythondataviewer:30285071 vscod805cf:30301675 pythonvspyt200:30340761 binariesv615:30325510 bridge0708:30335490 bridge0723:30353136 vsaa593:30376534 pythonvs932:30410667 vscop804:30404766 vscop940:30404999 vsrem710cf:30416617 vscexrecpromp3t1:30407762 ```

[ssbarnea]

I think you may be right as I tried to write invalid keys even inside .schema.json files and I did not spot any problems being reported.

One very annoying thing about JSON editing is that the current schema is not displayed to the user and you never know if current document is using a JSON schema or none at all. We can look at vscode-yaml extension that uses the same JSON schemas to validate YAML files and that extension does display the current schema in a header on top of the document, even the schema file is clickable and you can inspect it, very useful, especially as is not uncommon to encounter files using wrong schemas.

[aeschli]

Since the last release, the language indicator in the status bar shows if (and what) schema was used. https://code.visualstudio.com/updates/v1_63#_json-language-indicator

[ssbarnea]

Something is confusing here, especially as JSON schemas are using JSON format, not jsonc. Documentation shows "JSON with comments" with is incompatible with json, basically an invalid json if it contains any comment.

I check with purse JSON and I found another issue: it seems that the tooltip hint appears only when you hover over {} and not over the language of the document. When you hover over the JSON text you only see the "Select language" hover.

That is quite confusing and diverging from the documented screenshot which indicates as the entire section as being a single statusbar element (you see the highlight being showed for the entire {} JSON block.

The {} status presence is extremely small hand hard to hover over with mouse (probably impossible for touch screens but i am not one of those). The fact

I think that we really need to ensure that we have a single hover over the entire {} JSON text and not two, current behavior is very confusing as nobody would imagine that when you move over another part of the same element you get something else.

There is another issue related to discoverability of this feature and exposing the fact that a document is using a schema or not. I think that we need to expose presence/absence of the schema in a way that does not require user to perform an action. If a header is not added to the document with current schema we maybe can at least change the appearance of the status bar entry to indicate a schema being on/off, maybe color or different text like {!} and {}?

[aeschli]

@ssbarnea If your mode says JSON with comment, but it shouldn't, check your settings if you have associated the file name with JSONC. If that's not the problem, please file a new issue with reproducible steps (For me, schemas show as JSON).

Yes, that's how the language indicator works, you have to hover over the {}. Please file a new issue with your feedback and suggestion on the language indicator. The language indicator is a cross language feature. You can also see it with TypeScript.

[aeschli]

With schema associations, we currently only support associating to a schema resource, but not a schema reference

In "json.schemas", "url": "http://localhost:8080/my.schema.json#/$defs/inner_schema", is not supported. only http://localhost:8080/my.schema.json is currently supported.

Same when using $schema. You can workaround by having a pseudo resource:

http://localhost:8080/my.inner.schema.json with content

{
   "$ref": "my.schema.json#/$defs/inner_schema"
}

[wwahammy]

Hi @aeschli, is associating with a schema reference on the roadmap? And if so, any sense on when it might be completed or what we can do to make that possible?

[aeschli]

Currently no work planned but if you want to look at it, the code is in https://github.com/microsoft/vscode-json-languageservice/blob/e70857a34984391c63f93bfe635cd5bc47e627e7/src/services/jsonSchemaService.ts#L683

[wwahammy]

I'd consider contributing to address it but I can't agree to the Microsoft CLA. Sorry.