feat: add oclif pretty printer #27
Conversation
e1ec000 to
cdb0028
Compare
1a49ffe to
abd450a
Compare
db79e25 to
4c56cfc
Compare
Thanks @rizzlesauce for your contribution on #19 and highlighting the augmenting the error. Some of those ideas are pulled into this commit. Co-authored-by: Ross Adamson <[email protected]>
41a87bc to
fb4718a
Compare
cb22dbb to
b0672bb
Compare
| /** | ||
| * a suggestion that may be useful or provide additional context | ||
| */ | ||
| suggestion?: string; |
There was a problem hiding this comment.
We have found that we typically want multiple suggestions. https://github.com/forcedotcom/cli-packages/blob/develop/packages/command/src/sfdxCommand.ts#L503
| * a url to find out more information related to this error | ||
| * or fixing the error | ||
| */ | ||
| ref?: string; |
| // and is like either Error or Warning | ||
| const formattedHeader = message ? `${errorSuffix || 'Error'}: ${message}` : undefined | ||
| const formattedCode = code ? `Code: ${code}` : undefined | ||
| const formattedSuggestion = suggestion ? `Suggestion: ${suggestion}` : undefined |
There was a problem hiding this comment.
The Salesforce CLI says "Try this:". I like that a little more than "Suggestion:" but I don't care all that much. It might be worth it to have doc weigh-in. Or I guess to say it another way, if the Salesforce CLI would ever want to use this standard oclif error format, we would want to run it by doc.
| */ | ||
| export interface OclifError { | ||
| oclif: { | ||
| exit?: number | false; |
There was a problem hiding this comment.
How come this is in an oclif property but the other things like ref, code etc are on the actual error object? I always thought the exitCode should be on the error but a personal opinion.
In any case, this is our error object. Some stuff is specific to Salesforce like labels, but having the properties like actions vs. suggestion would be nice.
There was a problem hiding this comment.
This was more for backwards compatibility with the existing structure of cli error and the oclif property that was defined prior. Then the handle function expects it. It's unlikely people would have a different version of the @oclif/errors or would be creating their own errors with oclif.exit but we didn't want to risk it. Instead we wanted to call out it as an oclif error concern one that isn't involved with the display of the error. With your exitCode are you using a custom handle function in bin/run, too?
|
FYI this was a breaking change as |
closes #28
Adds a
prettyPrintfunction along with anPrettyPrintableInterfacewith the interface it works with. This is used in the handle function in place of usingrendermethods on Error objects. Pulling out the rendering of an error to a function and not having it be based on an error method allows theprettyPrintfunction to be used at any point by oclif developers (ie: in a command instance'scatchmethod). It also allows different classes of errors to be pretty printed.