-
Notifications
You must be signed in to change notification settings - Fork 110
Allow setting tags per log statement #23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@mattcasey curious as to what makes |
|
lgtm. |
Allow setting tags per log statement
|
@indexzero i still think we may want to concat in this case rather than override. |
|
mmm ... idk. Semantically I could see how that would bother me. |
|
e.g. "I only want to send THESE tags, nothing else!" |
|
@indexzero eh i guess my thought there is that IF you were to define global tags, i may want to add custom tags inheriting those global ones for different type of log messages. But since it defaults to the ID i could see it being less of an expectation. |
|
but im biased as this is how i made the |
|
yeah, it's also likely you keep them in the outer scope when you pass them into the var winston = require('winston'),
Loggly = require('winston-loggly');
var tags = ['this', 'that', 'the-other'];
var logger = new winston.Logger({
transports: [
new Loggly({ tags: tags })
]
});
logger.info('hey, a log!', {
tags: tags.concat(['custom-tags', 'over-here', 'with-default-tags-too'])
}); |
|
@indexzero well i do believe we may have differing assumptions as this still feels weird to me. Since the pull-request was for this way, we can leave it at that ;). |
Use default tags in `node-loggly` client
|
Hey guys! Thanks for accepting our PR. It didn't cross my mind to allow inheriting the tags. I could live with either way, just so long as we can add specific tags along-side each message :) |
helper method to call process exit
In the original code, "meta.tags" never gets used because this.tags is always set.