winston: Console transport does not write to debug console

Please tell us about your environment:

  • winston version?
    • winston@2
    • 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.

About this issue

  • Original URL
  • State: open
  • Created 6 years ago
  • Reactions: 20
  • Comments: 15 (3 by maintainers)

Most upvoted comments

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…

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()]
});

change to use integratedTerminal

  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch Program",
      "program": "${workspaceFolder}/index.js",
      "console": "integratedTerminal",
    }
  ]
}```

Please check on my proposal solving this in #1836

“console”: “integratedTerminal”,

“console”: “integratedTerminal” … This did the magic for me… After spending 2 hours. Thank you.

I extended this a bit:

/* eslint-disable @typescript-eslint/explicit-module-boundary-types */
/* eslint-disable @typescript-eslint/no-explicit-any */
import { LEVEL } from 'triple-beam';
import Transport from 'winston-transport';

// inspired by https://github.com/winstonjs/winston/issues/1544#issuecomment-499362387
export class SimpleConsoleTransport extends Transport {
  private getLogMethod(level: string) {
    if (level === 'debug') {
      return console.debug;
    } else if (level === 'info') {
      return console.info;
    } else if (level === 'critical' || level === 'error') {
      return console.error;
    } else if (level === 'warning') {
      return console.warn;
    } else {
      return console.log;
    }
  }

  override log(info: any, callback: any): void {
    setImmediate(() => this.emit('logged', info));
    const logMethod = this.getLogMethod(info[LEVEL]);
    const date = new Date();
    if (info.logStack) {
      logMethod(
        `${date.getHours()}:${date.getMinutes()}`,
        info.message,
        info.logStack
      );
    } else {
      logMethod(`${date.getHours()}:${date.getMinutes()}`, info.message);
    }
    if (callback) {
      callback();
    }
  }
}

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 .