Winston: Console transport does not write to debug console

[sirockin]

Please tell us about your environment:

• _winston version?_
  
  
  
  • [ ] winston@2
  
  
  • [x] winston@3
  
  
• _node -v outputs: v10.1.0
• _Operating System?_ Windows
• _Language?_ TypeScript

What is the problem?

When I use the built in Console transport, it will write to console when running normally (eg node ./dist/index.js ) but not to the debug console when I debug from Visual Studio Code. Standard calls to console.log()/warn()/error() do write to the debug console.

What do you expect to happen instead?

I expect all messages to write to the debug console as they would to the standard console when running normally.

Other information

The problem seems to be the use of _stderr.write() and _stdout.write() in the log() method of the transport implementation. If I replace the condition in the if statements at 49, 62 and 77 with false so that the standard console.log()/warn()/error() functions get called, the output does reach the console output. Obviously an undesirable side-effect is that the custom eol gets ignored.

[DABH]

Feels like more of a vscode bug -- why does their debug console have props like _stdout if we can't successfully write to it like that? Of course, you could have a modified transport like your workaround that works for vscode, but that may not be ideal. If you think this is something that needs to be fixed in winston feel free to offer any ideas :) But I don't think winston should check whether it's running in vscode, rather it seems like vscode's console should behave better.

[adi7ya]

@sirockin Are you developing a vscode extension? I came across this similar issue in vsode. Anyways, you can override the log method for console transport to make it work.

[indexzero]

We should address this, but needs more investigation.

[victorandree]

I just ran into this issue and wanted to add my very simple idea: Just use console.log, console.warn and console.error 😄

Right now, Winston is checking for [console._stderr] and [console._stdout], preferring to write to those streams directly, but falling back to using console.warn, console.error and console.log if not available. These properties (_stderr and _stdout) are available on the global console instance in node.js, however, they're not documented as being part of the [console] API nor are they enumerable.

What's the upside to using the streams directly in Winston over calling the methods? To me, console in a Javascript context means specifically the console object, not "console" in general or as a proxy for streams. Wouldn't the methods always work? Especially since there is a built-in stream transport in Winston, I would interpret "console" as appropriate for basically local development.

VS Code does _have_ the corresponding properties (probably because it's running on node), but its default "capture" for the debug console is "console" -- which probably means they've installed hooks specifically on the console.log calls, not on the streams themselves. I.e. VS Code is generating output, but not capturing it. It's probably related to this file

As others have mentioned, you can change which output VS Code captures, or change what the "console" transport does in Winston.

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch Program",
      "program": "${workspaceFolder}/index.js",
      // Capture "std" instead of "console"
      "outputCapture": "std"
    }
  ]
}

Note, if you follow the linked advice from @adi7ya, VS Code will output the line where console.log got called -- which is not where you called Winston, but the line in your overridden log. So, it might be only marginally useful...

[DABH]

Checking with VS Code folks to see whether we can make the necessary vsc settings for console transport output capturing the defaults: https://github.com/Microsoft/vscode/issues/69959 . Otherwise, the necessary vsc setting changes are linked from my comment there. ^^It's a valid question though, for the console transport, if a bunch of popular editors won't do the "right" thing by default, then maybe we should just change the behavior of the console transport cc @indexzero .

[melbourne2991]

This also bit me, could not agree more with @victorandree.

I'm using this very barebones transport for my own purposes at the moment if anyone else finds it useful:

import winston from "winston";
import Transport from "winston-transport";

const { MESSAGE } = require("triple-beam");
const level = process.env.LOG_LEVEL || "info";

class SimpleConsoleTransport extends Transport {
  log = (info: any, callback: any) => {
    setImmediate(() => this.emit("logged", info));

    console.log(info[MESSAGE]);

    if (callback) {
      callback();
    }
  };
}

export const logger = winston.createLogger({
  level,
  defaultMeta: {},
  transports: [new SimpleConsoleTransport()]
});

[baybal]

Please check on my proposal solving this in #1836

[Jimbly]

Also ran into this issue, and it does not appear to be VSCode-specific - if I run node --inspect and then attach to it from Chrome with chrome://inspect I see only calls to console.log/etc and not anything going to the Console transport.

[hanrea]

https://github.com/microsoft/vscode/issues/69959#issuecomment-480391201