Clarify prettyPrint documentation

[AleksandrSl]

I think that there are some old "code" in the docs about pretty print.

For example this

  function isPinoLog (log) {
    return log && (log.hasOwnProperty('v') && log.v === 1)
  }

function. From this #623 I understood that v was removed some time ago.

Also there is no infromation about why type of inputData could be different. Based on pino code it seems to me that object is always passed. If there are acutally another cases, maybe it will be helpfull to clarify when they are possible.

[mcollina]

Would you like to send a PR?

[AleksandrSl]

Yaeh, I can remove mentions of v in docs, but I'm not sure about prettifier inputData type clarification.

[mcollina]

I think it should be changed by the field
used by pino-pretty

[AleksandrSl]

Sorry, I don't fully understand what

it should be changed by the field
used by pino-pretty

means

[AleksandrSl]

Maybe string is passed when prettifier is used with pipe (as stated in docs - cat app.log | pino-pretty), and if prettifier is registered in app it will always get objects? Then this can be mentioned in docs and we can write less boiler plate in custom prettifiers, if they are not supposed to be used with pipes.

[mcollina]

I don't understand :/

[AleksandrSl]

In pretty print docs

  return function prettifier (inputData) {
    let logObject
    if (typeof inputData === 'string') {
      logObject = someJsonParser(inputData)
    } else if (isObject(inputData)) {
      logObject = inputData
    }
    if (!logObject) return inputData
    // implement prettification
  }

it's stated that prettifier function for some reason could get from pino two types of inputData - string and Object. While in the pino code, prettifier function is only called with Object. So I don't understand why string option exist.
Maybe this example was taken from pino-pretty, which has an option to parse logs from stream (i.e. cat app.log | pino-pretty) and in that case prettifier function could recieve string?

I think that prettifier example could be simplified, because you could write prettifier that works only from code and doesn't support piping logs into it.

[jsumners]

Please read the text in that section of the docs prior to that code sample. It very clearly explains the example.

[AleksandrSl]

@jsumners

Pino prettifier modules are extra modules that provide a CLI for parsing NDJSON log lines piped via stdin and expose an API which conforms to the Pino metadata streams API.

The API requires modules provide a factory function which returns a prettifier function. This prettifier function must accept either a string of NDJSON or a Pino log object.

There is no info when string can be passed. I wrote prettifier myself, that works with pino, and doesn't work with string. From my point of view prettifier needn't to be a CLI, simple function would suffice for most usages.
(Stupid reason why I can't just include this string check as in example - test coverage. I couldn't come up with test case, when string is passed to prettifier, so this statement is uncovered)

[jsumners]

Literally the first sentence in your quote describes when a string will be passed in. If you want to write a prettifier that doesn't support CLI usage, that's your prerogative. But we do not advocate doing so. Our docs outline what we expect in a prettifier to be considered a compliant prettifier.

[AleksandrSl]

Ok, so supplying simple function as prettifier is not how it's supposed to be used?

Literally the first sentence in your quote describes when a string will be passed in.
After our discussion I understood, it wasn't so transparent.

I used prettifier as simple function to easily migrate from bunyan where 'raw' stream was used to prettify output. Just thought it may be useful to mention in docs.

[AleksandrSl]

#510

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.