Hmm, this seems to change default behavior, which might require a major version bump. VSCode might be a better place for this to be fixed, especially if the impact is intended only for that one environment.

I believe this would resolve my feature request #2175 and others like it. I'm not sure how it would change the default behavior since the default value is false, so the statement:

if (console._stderr && !this.forceConsole)

would evaluate to the same as before if this prop wasn't set.

Found this open PR after spending way too long trying to find out why I wasn't getting Winston console logs in VSCode. Turns out it's because I'm attaching to the process (required in my case), and stderr/stdout can't be captured in that config. Setting "outputCapture": "std", as suggested in other linked issues is not a solution as that only works when VSCode is launching the node process, not when attaching to a running node process.

Would love to have this option available as it would enable VSCode to actually see the logs I want to write with Winston.

I agree that it doesn't look like this is introducing a breaking change. I'm okay with merging this but it would be good to have some documentation (even just a comment) somewhere explaining that you may need to set this option with VSCode. Enough people are using VSCode that maybe that's worth a line in the README? @neilenns , would you feel up to the task of adding some brief documentation somewhere for this?

(can be a separate PR - also anyone else reading this is more than welcome to do this 🙏)

Yep, I'd be happy to and will later today!

Cool, you rock!! 🎸

I, like presumably many others, do console.log = logger.log.bind(logger) (etc), to capture all console.log calls from all modules into my logging stream (and previously use something like the SimpleConsoleTransport in #1544 to get the logs showing up in Node Inspector / VSCode / etc). Unfortunately this fix doesn't actually help (causes an infinite recursion / call stack exceeded crash). Probably just need to save a reference to the global console at the time of logger instantiation and it'd be good though?

@Jimbly @neilenns If you think saving a copy of the global console or some other mod to this PR would be an improvement, please open another quick PR and let's get those fixes/improvements in there. With a test case would be ideal, but let's just do what we can to address this properly once and for all, I know this and related issues like #1544 have been open for a while. Appreciate your help in figuring out all these corner cases and details.

I'm not an expert at all in this unfortunately, just someone who got tripped up with the whole "can't capture in vscode when attaching to node.js" mess.

If you think saving a copy of the global console or some other mod to this PR would be an improvement, please open another quick PR and let's get those fixes/improvements in there.

Looking at this a bit more, the changed proposed in #2474 might fix the infinite recursion issue @Jimbly hit? Since it doesn't call console.log() directly and instead uses inspector.console to log?

I manually applied a variation of the change in #2474 and confirmed it does not have any issue with infinite recursion. In my main .ts file I added this:

import mainLogger from "@utils/logger";
console.log = mainLogger.log.bind(mainLogger);

And everything logs correctly to the console.