feat: allow custom log msg formatters

[stanimirovv]

PR Checklist

Implements option to have custom log formatters as discussed here:
#9281

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

• Feature

What is the current behavior?

Custom log message formaters aren't supported.

Issue Number: #9281

What is the new behavior?

Custom log message formaters are supported

Does this PR introduce a breaking change?

• No

Other information

[coveralls]

Pull Request Test Coverage Report for Build 29fdf5da-5e63-4e46-a11a-de81f6c77791

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 94.119%

---

Totals
Change from base Build c8c9b542-da7b-4884-a67d-faf6caf0ba8d:	0.0%
Covered Lines:	5761
Relevant Lines:	6121

---

💛 - Coveralls

[micalevisk]

I think having this interface wouldn't be that easy to write the output that that Issue need because pidMessage is too tied with the default formatting and uses that color function

Can you try to rewrite this formatMessage like this:

protected formatMessage(
  pid: number,
  logLevel: string,
  context: string,
  timestampDiff: number,
  output: string,
): string {
  return `` ...
}

but then we'll need to change the updateAndGetTimestampDiff method to extract the coloring stuff from it and make it return a number instead of string.

And then make formatMessage return an string with the color applied instead of applying it on printMessages. But yeah, that could be a bit harsh

[stanimirovv]

Yeah I think this may be better, I will refactor it with your suggestions.

[stanimirovv]

@micalevisk @kamilmysliwiec

So with the latest changes we are more or less like the first version.
I am not 100% sure if the format version should just place the arguments or also be able to generate them.

The minimal implementation is here: stanimirovv@89d9765

The "accept less arguments and do more" implementation is here (also the current one):
https://github.com/stanimirovv/nest/blob/feat/custom-logger-formatters/packages/common/services/console-logger.service.ts#L192

Personally I lean towards the second version because you have more control - over colors for example.

What is the intent - to allow some control or full control ?
If some control - go with stanimirovv@89d9765
If full go with - https://github.com/stanimirovv/nest/blob/feat/custom-logger-formatters/packages/common/services/console-logger.service.ts#L192

does that make sense ?

[kamilmysliwiec]

This approach stanimirovv@89d9765 better fits our needs but we should also allow opt-in coloring the messages. In this case, we should probably declare another dedicated method (let's say colorize) that takes the same set of arguments as formatMessages and adds colors. This method should be executed from within the formatMessages and have protected modifier to make it feasible to call it (if needed) from within the custom logger implementation.

[stanimirovv]

One final question -

Wouldn't it be a simpler interface if colorize takes a single argument and returns it colorised ?
function colorize(str: string): string
It will be called for the 2 parts of the message colored currently.
That way the user may add custom colorized elements to the log message.
But, again, depends on the intent.

The alternative is to have the following signature:

function colorize(
    pidMessage: string,
    formattedLogLevel: string,
    contextMessage: string,
    output: string,
    timestampDiff: string,): 

    [
      pidMessage: string,
      formattedLogLevel: string,
      contextMessage: string,
      output: string,
      timestampDiff: string,
    ]

[kamilmysliwiec]

Yeah, I think as long as we make getColorByLogLevel protected as well (to make it accessible) it could take two arguments (one being a message to format and the second - optional - color to be used that defaults to this.getColorByLogLever())

[stanimirovv]

I think we should be very close:

1. I extracted the colorize method and moved all logic having to do with colors into the formatMessage function as discussed
2. I took the liberty to extract one more protected message - stringifyMessage I can change it to private, but it felt like something that should also optionally be configurable -> the way the objects are serialized.

[kamilmysliwiec]

LGTM