Winston: Console logger - use console.log instead of process.stdout.write?

[roblourens]

I noticed that you write to process.stdout.write instead of console.log here: https://github.com/winstonjs/winston/blob/master/lib/winston/transports/console.js#L121, and I see in issues like this - https://github.com/Microsoft/vscode/issues/19750 - that process.stdout.write isn't sent over the v8-inspector debug protocol socket. So if users are using vscode or chrome devtools to debug Node, they won't see those messages. If you use console.log instead, they will see them. Is there anything blocking you from using console.log instead?

[DrYSG]

Same issue here:

I have an addendum to this. The issue seems to be with the colored text debug messages that the winston (v 2.3.1) logging package puts to the console. Simple text console.debug statements work. In the screen shot below you see the result of what it looks like in the console (CMD) vs, VSCode: (the first line is a console.log() message, the rest are from winston (which writes both to a log file, and to the console).

[indexzero]

Looks like the VSCode folks have fixed this upstream for all logging libraries, going to close this.

I agree with this sentiment on the issue.

[sgronblo]

This seems to affect Lambdas as well...

What's wrong with just making this configurable?

[LuukMoret]

Having the same issue with AWS Lambda

[twk-b]

We still have this block of code to make it work in chrome inspector,
attached to a recent node 8;
and just tested it recently and its still required, otherwise no logs...

// monkey patch to make logging work in inspector, using console.log
// https://github.com/Microsoft/vscode/issues/19750
// https://github.com/winstonjs/winston/issues/981
var winstonCommon = require('winston/lib/winston/common');
winston.transports.Console.prototype.log = function (level, message,
meta, callback) {
const output = winstonCommon.log(Object.assign({}, this, {
level: level,
message: message,
meta: meta
}));
// eslint-disable-next-line no-console
consolelevel in console ? level : 'log';
setImmediate(callback, null, true);
};

On Tue, Feb 6, 2018 at 6:00 AM, Luuk Moret [e-mail] wrote:

Having the same issue with AWS Lambda

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/winstonjs/winston/issues/981#issuecomment-363414861,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIc_zColv43MCuaXPErr6A3ywLBDAzFTks5tSE0FgaJpZM4L42Vk
.

[gartz]

I released a module that will help on that: https://github.com/gartz/node-bind-std-to-console

[luatnd]

After failed with node-bind-std-to-console.
I end up with this solution:

logger.add(supportNodeInspect(new winston.transports.Console({
        format: winston.format.simple()
      })));

/**
 * Override the winston console transport to support node --inspect, nodemon --inspect
 * Because winston will use stdout, stderror with higher priority than console.log
 */
function supportNodeInspect(winstonTransportsConsoleInstance) {
  const originLog = winstonTransportsConsoleInstance.log.bind(winstonTransportsConsoleInstance);

  // Override log fn to support log to node --inspect
  winstonTransportsConsoleInstance.log = (info, callback) => {
    originLog(info, callback);

    const {
            level,
            message,
            [LEVEL]: l,
            [MESSAGE]: m,
            [SPLAT]: s,
            ...meta
          } = info;
    console[level in console ? level : 'log'](message, meta);
  }

  return winstonTransportsConsoleInstance;
}

[jasonrberk]

just to share, it appears AWS is still not populating the CW logs with the TS or Request ID when using the default Console transport

I found this https://docs.aws.amazon.com/lambda/latest/dg/nodejs-logging.html

To output logs from your function code, you can use methods on the console object, or any logging library that writes to stdout or stderr.

but my logs are still missing the details

[HAMPLENI]

Looks like the VSCode folks have fixed this upstream for all logging libraries, going to close this.

I agree with this sentiment on the issue.

Sadly, that VS Code launch configuration option does not seem to work in my testing in conjunction with attaching VS Code's debugger to a running process, which is our case:

https://github.com/Microsoft/vscode/issues/19750#issuecomment-333584220