Vscode unable to resolve parts of the schema

Describe the bug

According to redhat-developer/yaml-language-server#585 and microsoft/vscode-json-languageservice#123 the use of hashes to reference eternal schemas is not supported.
$ref '/definitions/schemaArray' in 'http://asyncapi.com/schema-store/2.4.0.json' can not be resolved.

How to Reproduce

Create a new asyncapi.json or asyncapi.yaml file in vscode with the yaml extention installed.

Expected behavior

The schema should resolve by the language servers used by the extention.

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

Thanks for reporting this one, I saw the issue but had no idea that it depends not really on the yaml plugin but actually further on.

I don't think we should count on dependencies to fix the problem.

Feel to me like the best would be to plug into our release process of binding definitions into one schema like https://github.com/asyncapi/spec-json-schemas/blob/master/schemas/2.4.0.json and extend it with dereferencing too 🤔

@jonaslagoni you worked on the bundling. What do you think?

@smoya thoughts? resolving all references in the main schema as part of the release should also decrease amount of request for particular definitions

@magicmatatjahu it will be good for the parser performance when it compiles schema, right? although in exchange the JSON file will be larger. Performance is more important I think

@fmvilas @dalelane thoughts?

Without looking into it, I am pretty sure it's because the reference is not accurately resolved to this schema:

spec-json-schemas/schemas/2.4.0.json

Line 486 in 83c03f2

"schemaArray": {

When this reference is encountered:

spec-json-schemas/schemas/2.4.0.json

Line 601 in 83c03f2

"$ref": "#/definitions/schemaArray"

it MUST use the schema $id most recently encountered

spec-json-schemas/schemas/2.4.0.json

Line 483 in 83c03f2

"$id": "http://json-schema.org/draft-07/schema",

to resolve the relevant references and NOT expect that the root 2.1.0.yaml schema contains a schema at #/definitions/schemaArray i.e. the fully resolved reference should be http://json-schema.org/draft-07/schema#/definitions/schemaArray.

When this reference is encountered:
spec-json-schemas/schemas/2.4.0.json
Line 601 in 83c03f2
"$ref": "#/definitions/schemaArray"
it MUST use the schema $id most recently encountered
spec-json-schemas/schemas/2.4.0.json
Line 483 in 83c03f2
"$id": "http://json-schema.org/draft-07/schema",
to resolve the relevant references and NOT expect that the root 2.1.0.yaml schema contains a schema at #/definitions/schemaArray i.e. the fully resolved reference should be http://json-schema.org/draft-07/schema#/definitions/schemaArray.

I don't think it will ever be logical to me 😅

@jonaslagoni we know that there is a problem, but it is outside our reach, thus my suggestion is that we basically resolve all references, inline them in the schema that we publish (ignoring circular if we have these)

@jonaslagoni we know that there is a problem, but it is outside our reach, thus my suggestion is that we basically resolve all references, inline them in the schema that we publish (ignoring circular if we have these)

It's definitely a possibility, but ignoring circular is just not an option I think.

An alternative approach is that we create our "own" bundling behavior and change the $refs to be absolute from the perspective of the root object I.e. the bundling behavior would change the reference

spec-json-schemas/schemas/2.4.0.json

Line 601 in 83c03f2

"$ref": "#/definitions/schemaArray"

to /definitions/http://json-schema.org/draft-07/schema/definitions/schemaArray.

I think that could work because then we are no longer expecting tools that resolve it to fully support the bundling and dereferencing behavior of JSON Schema. At least it could be a bandage on the wound until the tooling has further matured.

You might need to play around with what works.

but the same with "$ref": "http://asyncapi.com/definitions/2.4.0/specificationExtension.json" right? and change to #/definitions/http://asyncapi.com/definitions/2.4.0/specificationExtension.json, as we are not sure how resolvers from community work, they can also fetch from http://asyncapi.com/definitions/2.4.0/specificationExtension.json instead of definitions, right?

until the tooling has further matured

😃

@jonaslagoni ok, now I think I get it, you wrote /definitions/http://json-schema.org/draft-07/schema/definitions/schemaArray as it is there already in the file. Better this way, than make tooling fetch from asyncapi.com

we create our "own" bundling behavior

I think it is ok to follow the current bundler, but then just after bundling just traverse the document again and make small adjustments, no?

That should be possible yes.

@derberg not sure how long you are with your implementation, but I added an issue for the bundler we used to see if it won't make sense to solve this natively there: hyperjump-io/json-schema-bundle#9

@jonaslagoni I planned to work on this next week. So yeah, lemme know if you plan to be first 😄

FYI I'm encountering this same issue

Opened a PR to fix this issue once and for all

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

Still relevant.

works like a charm now

and I know @AceTheCreator will follow with more description and examples inside schema to put the autocompletion on a higher level

@ivangsa pinging you as you might want to know in regards to vscode plugin maybe