-
Notifications
You must be signed in to change notification settings - Fork 8
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
Intercepting the 'time' section of the log message? #7
Comments
Yeah, because it is supposed that if you're overriding the // NB: part of the Ololog library, no need to `npm install` separately
const { cyan, yellow } = require ('ansicolor')
const logging = log.configure ({
time: {
yes: true,
print: date => cyan.dim ('[' + date.toISOString () + '] ') + yellow ('(INFO) ')
}
}) Does that help? |
Yes. That worked. Thank you very much for the help. Any suggestions about how to insert |
What do you want to use to switch between INFO/WARNING/ERROR? I guess, I mean, There might be a problem with that, as we clearly need to do that not in the get error () { return this.configure ({ render: { consoleMethod: 'error' } }) },
get warn () { return this.configure ({ render: { consoleMethod: 'warn' } }) },
get info () { return this.configure ({ render: { consoleMethod: 'info' } }) }, It might be convenient if we could access that config parameter from other stages, but that is not currently possible (although we could rewrite the https://github.com/xpl/pipez/blob/master/pipez.js to make it possible, but that might not be easy...) As a quick workaround, we could introduce a new pre-defined stage in the Ololog itself, that would inject the INFO/WARNING/ERROR tag (and change the Will it solve your problem? |
Hi, Thanks for looking into this, thank you for your time. This sounds a bit too much of a work for a feature that probably will not improve the outcome other than cosmetic results. I don't want to disrupt your dev process with something that is not going to add a lot in return. I am using the const logger = log.configure ({
time: {
yes: true,
print: date => cyan.dim ('[' + date.toISOString () + '] ') + yellow ('(INFO) ')
},
locate: { shift: 1 }
})
const logging = {
info: function(message) {
\\ Customise and handle additional features etc.
logger(yellow('INFO)' + message)
},
warning: function(message) {
\\ Customise and handle additional features etc.
logger(cyan('WARNING)' + message)
}
} (Excuse my pseudo-code, I do not have access to my actual code right now.) The point of wrapping this is to customise bits and pieces in order for this to fit my needs and improve readability. For example, if I am verbosing an object, I would like to have it in a different colour and on a new line (please see the example below). Then I do this: // After importing the logging wrapper.
log.info(`Exchange returns the following pairs:\n ${JSON.stringify(myPairsArray)}`) So I get,
So, I think everything is fine so far. Unless my wrapper approach is pointless? :) Back to the question, maybe in the future, if there is more demand for this option by others etc. You might add a way to insert context sensitive bits that can be injected at the wrapper level. For example: const logging = {
info: function(message, id) {
/* Do stuff such as:
Injecting the ID into the log message so we know about the context it is coming from:
timestamp + ID + message
*/
}
} So you get:
which in return might allow a custom
At the end of the day, this is mostly cosmetic to certain level. I love your module. For python I am using a variant of this: |
@cryptoeraser I've added a new overrideable stage called The example code: const bullet = require ('string.bullet') // NB: these packages are part of Ololog, no need to install them separately
const { cyan, yellow, red, dim } = require ('ansicolor')
const log = require ('ololog').configure ({
locate: false,
time: true,
tag: (lines, {
level = '',
levelColor = { 'info': cyan, 'warn': yellow, 'error': red.bright.inverse },
clusterId
}) => {
const clusterStr = clusterId ? ('CLUSTER[' + (clusterId + '').padStart (2, '0') + ']') : ''
const levelStr = level && (levelColor[level] || (s => s)) (level.toUpperCase ())
return bullet (dim (clusterStr.padStart (10)) + '\t' + levelStr.padStart (6) + '\t', lines)
}
}) log.configure ({ tag: { clusterId: 1 } }) ('foo')
log.configure ({ tag: { clusterId: 3 } }).info ('bar')
log.configure ({ tag: { clusterId: 27 } }).error ('a multiline\nerror\nmessage') |
Also notice the usage of string.bullet — a little helper (that is a part of Ololog) that helps formatting multiline messages that do not spill below the added prefix. |
Yeah, I have seen your commit and I was already digging in the diffs :) Thank you very much! This is amazing! |
Hi,
Great tool. I especially love the fact that we can intercept and modify the
concat
andrender
stages.One thing I was not able to do:
I would like to format the
timestamp
in the following fashion:I know we can add a custom printer for the time, but that changes the output to:
which is not something that I would like to do? So here is what I am trying to achieve:
[
to the start and]
to the end of the timestamp.(INFO)
signature between the timestamp and the message block, so the second line of the message does not spill below the(INFO)
signature.So it looks a bit like this:
Obviously, I tried this:
as an attempt to intercept the text stream and try re-format it, but I got this:
... so the timestamp was not there :)
The text was updated successfully, but these errors were encountered: