winston: Console transport does not write to debug console
Please tell us about your environment:
winstonversion?-
winston@2 -
winston@3
-
- _
node -voutputs: 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)
I just ran into this issue and wanted to add my very simple idea: Just use
console.log,console.warnandconsole.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.errorandconsole.logif not available. These properties (_stderrand_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,
consolein a Javascript context means specifically theconsoleobject, not “console” in general or as a proxy for streams. Wouldn’t the methods always work? Especially since there is a built-instreamtransport 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.logcalls, not on the streams themselves. I.e. VS Code is generating output, but not capturing it. It’s probably related to this fileAs others have mentioned, you can change which output VS Code captures, or change what the “console” transport does in Winston.
Note, if you follow the linked advice from @adi7ya, VS Code will output the line where
console.loggot called – which is not where you called Winston, but the line in your overriddenlog. 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:
change to use integratedTerminal
Please check on my proposal solving this in #1836
“console”: “integratedTerminal” … This did the magic for me… After spending 2 hours. Thank you.
I extended this a bit:
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 .