Open ak1394 opened 3 years ago
Same, Postman only support version 3 for now so all our open api files have errors and the autocompletion is not working anymore.
From https://www.schemastore.org/api/json/catalog.json (URL of schema store catalog to use) at around the line 1684 where the openapi.json is defined it have the versions object which could be used to switch between version 3..0.x and version 3.1.x.
{
"name": "openapi.json",
"description": "A JSON schema for Open API documentation files",
"fileMatch": [
"openapi.json",
"openapi.yml",
"openapi.yaml"
],
"url": "https://raw.githubusercontent.com/OAI/OpenAPI-Specification/main/schemas/v3.1/schema.json",
"versions": {
"3.0": "https://raw.githubusercontent.com/OAI/OpenAPI-Specification/main/schemas/v3.0/schema.json",
"3.1": "https://raw.githubusercontent.com/OAI/OpenAPI-Specification/main/schemas/v3.1/schema.json"
}
},
"yaml.schemas": {
"https://raw.githubusercontent.com/OAI/OpenAPI-Specification/main/schemas/v3.0/schema.json": "openapi.yml",
},
it should accept now the version 3.0 but won't work for version 3.1
@JPinkney @gorkem I make some prototype of this, I want to allow users to choose schema, but I have two problems:
With Use: {version}
, Click on it will change used schema. In this case we don't need to have any non standard LSP communication API
But to implement this I need to add more non standard LSP communication API.
WDYT?
Just wanted to mention, that our extension uses redhat.vscode-yaml's registerContributor() to provide relevant schema based on the file contents.
Given that looking up schemastore catalog is pretty crude way of finding the schema (it only matches the file name, ignoring the file contents) perhaps schemastore should be ignored for the files where schema is known from registerContributor()?
That is not a bad idea. I think it makes sense that extension registered schemas takes precedence over anything else.
As an alternative, I noticed adding this line on top of your OpenAPI 3.0 YAML file will fix it in VS Code and in VS 2022 (which probably also uses this same lib). More info here: https://github.com/redhat-developer/yaml-language-server#using-inlined-schema
# yaml-language-server: $schema=https://raw.githubusercontent.com/OAI/OpenAPI-Specification/main/schemas/v3.0/schema.json
openapi: 3.0.0
info:
... etc
When using the 3.0 schema, I get an error that definitions/Schema/properties/multipleOf/exclusiveMinimum
must be a number.
It seems as if the extension is using a newer version of the JSON Schema spec to validate the OpenAPI schema than draft-04 like it declares.
It appears that the yaml-language-server
hack no longer works, and neither does adding
"yaml.schemas": {
"https://raw.githubusercontent.com/OAI/OpenAPI-Specification/main/schemas/v3.0/schema.json": "openapi.yml"
}
to settings.json
Can we get an update on this issue? AFAIK support for OpenAPI 3.1 is pretty low across tooling RN.
Over half a year and still not fixed.
This issue makes the extension completely unusable for even OpenAPI 3.0!
Note that when I try to drill down to a specific definition: https://raw.githubusercontent.com/OAI/OpenAPI-Specification/main/schemas/v3.1/schema.json#/$defs/response
It emits a wrong error saying Missing property "paths"
.
That schema does not have a property paths
.
Running into the same issue here. This is technically not an issue with the VSCode YAML extension, but the underlying yaml-language-server. There are a couple of Issues in that repo, but I think the most important one would be this one: YAML Language Server checks against JSON Schema Draft 7 instead of the defined one
The hacks/configurations of specifying the schema to use for OpenAPI no longer work due to the fact that the language server itself uses a newer JSON specification than what the OpenAPI 3.0 schema defines. Essentially, the core issue is that the language server ignores the $schema
line in schema files it references. This wouldn't just be an issue with OpenAPI, but any schema that hasn't been updated to use JSON Schema Draft 7. OpenAPI just happens to be the most recognized specification.
The above ticket has a comment around a fork of the language server that uses JSON Schema Draft 04, which would fix this issue, but this would likely just break other schemas that DO require Draft 07. Looking at the comments, it seems to already be an issue for people wanting to use Draft 2020-12.
I'd recommend anyone having this issue to voice them in the above Issue 780 in yaml-language-server.
I was able to work around this by migrating the OpenAPI v3.0 Schema from draft4 to draft7 locally using alterschema and adding this to .vscode/draft7-schema.json
and setting this in the yaml.schemas
in my .vscode/settings.json
Steps I used:
npx alterschema --from draft4 --to draft7 ./schema.json > ./draft7-schema.json
Ideally, this should be committed to a repo for github raw access like other schemas
yaml.schemas
in .vscode/settings.json
{
"yaml.schemas": {
".vscode/draft7-schema.json": [
"*openapi.yml",
"*openapi.yaml",
"openapi.yml",
"openapi.yaml",
]
}
}
Note: this seems to work, but I didnt really test the if the schema is 100% perfect as I just wanted this error to go away.
File with the schema definition for OpenAPI 3.0.X is now a yaml https://raw.githubusercontent.com/OAI/OpenAPI-Specification/refs/heads/main/schemas/v3.0/schema.yaml
But available here as JSON: https://raw.githubusercontent.com/OAI/OpenAPI-Specification/refs/heads/gh-pages/oas/3.0/schema/2021-09-28
Can also be found here: https://spec.openapis.org/
I try to set the option in VSCodium v1.93.0 and YAML extension v1.15.0
"yaml.schemas": {
"https://raw.githubusercontent.com/OAI/OpenAPI-Specification/refs/heads/main/schemas/v3.0/schema.yaml": "openapi.{yml,yaml}",
},
But it fails with the yaml files with this error:
Schema 'schema.yaml' is not valid:
/definitions/Schema/properties/multipleOf/exclusiveMinimum : must be number YAML(768)
VS Code YAML extension uses Schema Store https://www.schemastore.org/api/json/catalog.json to automatically guess and apply JSON Schemas to documents being edited.
My understanding is that if multiple schemas match a file, these schemas are combined and then used to validate the matching file.
It looks though, that schemastore.org contains schemas written in newer and yet supported by VS Code schema dialect.
In particular, I've started seeing that OpenAPI 3.1 schema https://raw.githubusercontent.com/OAI/OpenAPI-Specification/main/schemas/v3.1/schema.json which uses Draft 2020-12 dialect is being applied to OpenAPI files.
I'm an author of OpenAPI extension (which depends on Redhat YAML one) and I'm seeing users reporting errors which appear like OpenAPI 3.1 schemas are being arbitrarily applied to files they edit: https://github.com/42Crunch/vscode-openapi/issues/130
In particular complains are for the error messages which look like this:
Would it be possible (if I'm correct in my conclusion) to exclude unsupported schema dialects?