Support Custom Resolvers

[patrickDouglas]

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:

• spectral.resolverFile: Location of the resolver file to use when Custom $ref Resolving. If omitted, no resolver will be used. Paths are relative to the workspace.

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]

@patrickDouglas 👋 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]

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: #84)

[patrickDouglas]

@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]

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..