feat: export validate from the Parse module

[jpshack-at-palomar]

The oclif project I am working on includes a features that allow one to orchestrate the execution of a pipeline of Oclif commands. Since it supplies JSON to each command with args and flags it is wasteful to put the json back into a command line and then parse the flags and args out again. That said, we do want to validate the args and flags but now that Oclif better controls is exports, we do not have access to the needed validate function. This PR restores access to the validate call so that we do not have have to copy and reproduce all of that code in our project. We have been working off a private fork for this one change but are nearing release and would like to make things right ahead of that.

Thanks for your consideration!

[salesforce-cla]

Thanks for the contribution! Before we can merge this, we need @jpshackelford to sign the Salesforce Inc. Contributor License Agreement.

[jpshack-at-palomar]

I went to sign the CLA with both @jpshack-at-palomar and @jpshackelford (both my accounts) and received a message saying that I already signed (with both).

[jpshack-at-palomar]

@mdonnalley @cristiand391 Is this one-liner acceptable or should I pursue a more involved solution?

[cristiand391]

Since it supplies JSON to each command with args and flags it is wasteful to put the json back into a command line and then parse the flags and args out again. That said, we do want to validate the args and flags

validate requires a parser call already, how are you skipping parsing currently?
https://github.com/oclif/core/blob/95afb53de93218799dd5d8195794a260acc9b64a/src/parser/index.ts#L23C2-L25C34

For some specific code/types/interfaces we purposely stopped exporting them (easier to make changes in the parser, public types without public breaking changes), not sure if validate was in this case but it's tightly coupled to the parser.

[jpshack-at-palomar]

@cristiand391 Thanks for the response. We have implemented a yaml/json DSL that allows one to call oclif commands (we are using oclif's plugin system as our primary extension mechanism) by passing args and flags.

We look up the command by name using Config.findCommand (already exposed by oclif/core) and then build out Interfaces.ParserInput and Interfaces.ParserOutput which are also exposed by oclif/core then call Parser.validate({input, output}) to do additional validation. I am simplifying, but the point is that all the pieces we needed to do this were exposed except this one call to Parser.validate.

We learned quite a bit about the Oclif Parser in the process of building this system and there are definitely ways that we think the Parsing system could be rewritten and reorganized to make it cleaner, but given the interfaces that Oclif already exposes, we think this one-line change is likely to be the least invasive and disruptive without exposing much API surface that isn't already exposed. If you have an alternative you'd like us to pursue, we are certainly open to suggestions.

[cristiand391]

thanks for the context @jpshack-at-palomar

I think it's ok, we already expose the interface by exporting the parser so even if we didn't export validate we would still need a major release for breaking changes there.

just pushed a separate branch with your changes to run tests here, will merge when all is 🟢

[jpshack-at-palomar]

@cristiand391 Thanks very much!

I came to the same conclusion when looked at the interfaces that were exposed -- we won't be able to restructure the parsing system significantly without breaking changes later.

Super grateful for all that you and @mdonnalley have done for Oclif! Thanks again.

[cristiand391]

just 1 flakyNUT failure from plugin-data, safe to ignore:

     Error: Deleting org [email protected] failed due to: Error (1): ConcurrentRequests (Concurrent API Requests) Limit exceeded.