search

microsoft / vscode-json-languageservice

JSON language service extracted from VSCode to be reused, e.g in the Monaco editor.
Other
261 stars 110 forks source link

Synchronous validation #28

Open Levertion opened 6 years ago

Levertion commented 6 years ago

In some situations it is useful to support JSON where the set of required schemas is known before the validation is run. It appears to me, from my armchair (figure of speech) postulations, that the only required promises are in fetching schemas from a filesystem as decided by SchemaRequestService. In my case, this would be a single static schema.

However, the current api still requires that such cases happen in the infectious async world, which is not always valuable. Have you got any suggestions for how I could handle this/what changes would be required to support such a use case?

If this is out of scope, I will be forced to reimplement (using the powers vested in me by ctrl-c and ctrl-v) all of the logic in this library.

Many thanks!

Further Context: For my project https://github.com/Levertion/mcfunction-langserver, I know that the only required schema is https://github.com/Levertion/minecraft-json-schemas/blob/master/shared/minecraft_definitions.json, which doesn't reference any external files. As this is a language server implementation requiring JSON support, I thought that vscode-json-languageservice would be a suitable, but as my core api is synchronous, I would require large changes just to avoid this issue.

aeschli commented 6 years ago

Sure, we can add a second validation API doValidate2 that requires a schema and is sync.

You want to give it a try and make a PR?

Levertion commented 6 years ago

I'll give it a go! Thanks - I just wanted to check something like that could be useful for this library.

Levertion commented 5 years ago

I have worked out a way to do what I want by using https://www.npmjs.com/package/synchronous-promise. This means that your library requires no changes to support my usecase because you already allow using a custom promise constructor.

I'm not going to close this issue, as a cleaner solution would be ideal, although I won't object if you wish to.

azeemba commented 5 years ago

I was looking into implementing this but I found something unexpected so wanted to clarify. It seems that getDiagnostics can be either called with a JSONSchema or a ResolvedSchema. Since the former doesn't have a .error field, I am not sure how this line isn't erroring out.

Is this an issue? Or should the PR for this maintain this behavior?

aeschli commented 5 years ago

Thanks @azeemba, you are correct, there's a bug. I fixed it with a72b1c0723a076ecf4e362f24a7ddc379d42fbc6

Levertion commented 5 years ago

I did look into this and that was what stopped me contributing - I thought there was some really complex infrastructure in place to make that work...

aeschli commented 3 years ago

Is there still demand for this or plans to work on this?

my-tien commented 1 year ago

Yes, so my use case is the following: We have a monaco editor in which we do JSON validation against a given schema and additionally we want to log the diagnostics somewhere. Since the monaco editor doesn’t support simply reading out the diagnostics, we are forced to actually validate the same string again with vscode-json-languageservice.

Since at that point the schema and json string are already given, I would wish there was a simple synchronous validate(json, schema) and in my naive thinking this could be called by doValidation internally?

my-tien commented 1 year ago

Hi, is there any capacity to look into this issue? If I could receive some guidance I could also try to implement this in a PR.