Should we expose `options.serializers`?

[H4ad]

From what I understand, this is used to serialize a property value of the log message, so if I create the following object

{
  myKey: (value) => JSON.stringify(value),
}

It will use that function only to serialize the property myKey, the other properties will use the built-in serializers (JSON.stringify or safe-stable-stringify if JSON.stringify throws error).

Also, looking at the code https://github.com/pinojs/pino/blob/main/lib/tools.js#L128, it will serialize the root properties of the log object.

With this in mind, should we expose this serializers or should we enable the user to customize entirely the serialization by giving a property like jsonSerializer and passing the entire log object and expect a valid json from that function?

If we do that, people can use ajv, typia and other libraries to generate crazy fast serializers for their objects.

From another perspective, today people can use those libraries for a specific property they know they will log, for example: userDetails, if we find something like that, can use use ajv to create a special serializer just for that object.

[H4ad]

~Blocked by #4~

We will rewrite pino.

~Now blocked by: https://github.com/H4ad/nodejs-logging-proposal/issues/8~

The signature of the function will remain the same.

[H4ad]

I will remove it for v1, but I will probably add this later.

For now, I will just keep the stringify function.