Save the following into a file named app.js:
``` #!javascript
'use strict';
const winston = require('winston');
const log = new winston.Logger({
levels: {
error: 3,
warning: 4,
notice: 5,
info: 6,
debug: 7,
},
transports: [
new (winston.transports.Console)({
level: 'debug',
}),
],
});
log.error('test error');
log.warning('test warning');
log.notice('test notice');
log.info('test info');
log.debug('test debug');
```
node app.js > app.log 2>err.loglog.error and log.debug output both ended up in there (former expected, latter not expected). View the contents of app.log and notice that the log.warning, log.notice, and log.info output all ended up in there (as expected).node app.js > app.log 2>err.loglog.debugz output is now in app.log and _not_ in err.log.just found related issue #556 ... still trying to understand it, but wanted to get that out there before anyone wastes too much time investigating / responding
Found the answer here:
https://github.com/winstonjs/winston/blob/master/docs/transports.md
... i.e. setting the levels to log to stderr instead of stdout via stderrLevels transport option.
FWIW, I didn't find it very intuitive that this option would default to ['error', 'debug'], but that may be based on my own ignorance of how that default would make sense.
I'll let someone on the project close this issue after reading this feedback, but I need no additional help.
Debug logging does not indicate an error in my eyes. Good that it can be changed via stderrLevels, but shouldn't the default be ['error'] in stead of ['error', 'debug']?
Maybe I can see the sense of it, although I do not agree with it.
It might make sense under the following terms:
In this case, you'll have to search for your debug notices in the file/sql/loglly,
while stderr emits it to your console.
IMHO - It's a kinda twisted gotcha. I'm here just because I ran into it myself, and decided to share my observation.
It's of the kind of settings that are fit to development time, and nowhere else.
IMHO - this behavior should not the default, but enabled by the user.
I agree that this is a very strange default setting.
I'm building a system that runs commands locally, and it also runs its own commands over SSH in child processes too. And have been investigating why the local commands appeared to work (I'm not monitoring STDERR on the main local node process), but the same remote SSH commands were producing STDERR output (I'm throwing local exceptions when the child process's remote command has STDERR output).
First I thought it was something to do with SSH itself handling output differently until I ran further tests to rule SSH out, and after a while thought to look into Winston.
Thanks for posting this issue. This would have taken me a while longer to figure out otherwise.
Duplicate of #1024, which will remain open.
The feature has existed for a long time, but if enough folks are not happy with it then we can remove it as a breaking change in [email protected]
I think you should let the user decide.
maybe a setting console appender / transport.
+1 for leaving debug out of stderr.
Most helpful comment
Found the answer here:
https://github.com/winstonjs/winston/blob/master/docs/transports.md
... i.e. setting the levels to log to stderr instead of stdout via
stderrLevelstransport option.FWIW, I didn't find it very intuitive that this option would default to
['error', 'debug'], but that may be based on my own ignorance of how that default would make sense.I'll let someone on the project close this issue after reading this feedback, but I need no additional help.