Expose to the caller of .run() the fully resolved result

[nulltoken]

User story.
As a developer, I can access the fully resolved results of multiple calls to spectral.run(), so that I can apply some further custom processing on the standalone resulting object.

Is your feature request related to a problem?
We have to deal with multiple .yaml root files, each of them relying on remotes references.
Spectral is an amazing tool to lint each root file (and pointing at where each issue come from, on a file by file basis). However, eventually, we have to combine those files into a gigantic standalone OAS doc and apply some further linting (that only makes sense when all the files are combined).

Describe the solution you'd like
I'd like to be able to retrieve from each run() call the internally resolved result, so that I've only got to perform the final combining and the additional linting.

[P0lip]

Hey @nulltoken.
Thanks for another great feedback - really appreciate it!
In upcoming weeks, we'll be heavily focused on improving the JS API, therefore we are very likely to work around that particular codebase.
That said, I believe we can make it happen - it seems like it may turn out to be useful for the general audience.
Do you have any proposal for a method? I was thinking of getResolved or something similar, but open to other ideas.

I don't know when the change would take place, but hopefully, it makes its way as a part of 4.1 release.

[philsturgeon]

@nulltoken thanks for the kind words about Spectral's awesomeness. :D

I could do with understanding the base use case a bit more. I don't really understand what is happening with the combination of multiple documents or why.

[nulltoken]

@philsturgeon Our team is in charge of aggregating multiple openapi 2.0/3.0 yaml files from 20+ different teams.

Our build process validates each file individually then combine them in 10~ higher level namespaces.

All those files bear some metadata exposed through x- prefixed properties. Those props allows us to backtrack which team is responsible for each resource for instance, which server a particular path is routed to...

We currently use a custom built tool to do this. We're migrating to leverage the spectral API in a parallel thread which should greatly reduce the maintenance of rules.

Spectral seems a perfect fit to lint each file individually. However, eventually we have to apply some additional rules on the eventually combined definitions to ensure that the x- defined metadata properties are sound as a whole (eg. the server metadata defined in file A is legit, the server metadata defined in file B is legit, however, they both share the same identifier and expose different values).

Retrieving the internally resolved result from each spectral run would allow us to perform that combination in memory and then process it through another run() call using these additional rules.

Thoughts?