stoplightio / vscode-spectral

VS Code extension bringing the awesome Spectral JSON/YAML linter with OpenAPI/AsyncAPI support
https://marketplace.visualstudio.com/items?itemName=stoplight.spectral
Apache License 2.0
69 stars 22 forks source link

Support Custom Resolvers #23

Open patrickDouglas opened 4 years ago

patrickDouglas commented 4 years ago

Describe the solution you'd like Please add a new Setting that would allow for Custom $ref Resolving (which is already support by Spectral): https://meta.stoplight.io/docs/spectral/docs/guides/2-cli.md#custom-ref-resolving .

I would this it would be a new Setting spectral.resolverFile:

This path value would be passed to the Spectral CLI via the --resolver flag.

I might personally attempt this work in the near future if you don't get this done.

nulltoken commented 4 years ago

@patrickDouglas :wave: Interesting idea!

I might personally attempt this work in the near future

That would be great!

One little thingie that may be worth attention: As we want to be able to also lint unsaved/in-memory documents, the passed in custom resolver handling the file scheme will have to be wrapped (ie. upon resolving, try to find in the Documents collection, otherwise delegate to the custom resolver).

patrickDouglas commented 3 years ago

Has there been any movement on this? I personally think the best route would be to be able to define all appropriate CLI options in the .spectral.{yml|yaml|json} file, then this extension would just use that. Thoughts?

Another idea would be to just point to a JS File (in each workspace) that exports an instance of Spectral that the user would like to use (would potentially also help solve: https://github.com/stoplightio/vscode-spectral/issues/84)

patrickDouglas commented 3 years ago

@nulltoken I've started to dive into the code here, but I don't see how we can pass in resolvers as we have 1 shared instance of Spectral shared across all documents, which makes it hard. We could reinitialize the Shared Instance if the configuration changes (ie. settings or the workspace). That may work. Thoughts?

SirAppSec commented 3 months ago

I'm having a similiar use case where I want to use the custom resolver in the VSCode extention. Anyone have a solution for this? I'm thinking, instead, to derefrence in a custom function. but this seems more elegant, as it provide the visibility and elasticity of the resolver used..