Closed mcollina closed 3 years ago
I'd prefer to fully deprecate it from Pino. Let people pass in a transport or whatever that does it. I'd also like to keep pino-pretty
narrowed to its current focus: parsing stdin
. If necessary, and possible, I'd rather see us create pino-pretty-transport
to provide the transport.
Hi guys, I am willing to work on this.
Just to be clear, the intention of this is
prettyPrint
option from constructorpino-pretty
is that correct?
Do we want to show a warning when passing { prettyPrint: true }
in the constructor?
I have some code prepared for this, wait until I upload it (might take a few days).
For those bumping into the deprecation message and finding this issue, the solution is something like the following:
const transport = pino.transport({
target: 'pino-pretty',
options: { colorize: true }
})
const logger = pino({ level: env.LOG_LEVEL }, transport)
Note that transport is governed by the log level in the main options. If you only add the transport, you are restricted to the default log level (which is "info").
Hi,
I am using streams. What should I do to remove the deprecation message?
const loggerStream = () => {
const logPath = path.resolve(
process.platform === "win32"
? `${WIN_LOG_PATH}/${LOG_FILE}`
: `${getAppDataPath()}/${LOG_FILE}`
);
return multistream(
[
{
level: "error",
stream: createStream(logPath, LOG_ROTATION_SETTINGS),
},
{
level: "debug",
stream: createStream(logPath, LOG_ROTATION_SETTINGS),
},
{
stream: createStream(logPath, LOG_ROTATION_SETTINGS),
},
],
{ dedupe: true }
);
};
const logger = pino(
{
prettyPrint: {
colorize: true,
errorLikeObjectKeys: ["err", "error", "details"],
levelFirst: true,
translateTime: "SYS:hh:MM:ss TT dd-mm-yyyy",
ignore: "pid,hostname,service",
messageFormat: (log, messageKey) => {
return applyServiceStyles(log, messageKey);
},
},
level: process.env.LOG_LEVEL || "debug",
serializers: {
error: pino.stdSerializers.err,
},
},
loggerStream()
);
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.
We had too many folks complaining about how we load pino-pretty with yarn 2/3 and similar. I think we should either
1) require the user to pass in a reference to pino-pretty 2) make pino-pretty a full transport and let folks use it from there.