TJ's lib looks alright, having the option to control via environment
variables is probably an acceptable solution.
This discussion has led me to delve a little deeper into the winston source
code and I think there's a problem there for which I've raised an
issue/pull request on GitHub
(https:/
debug is quite okay, but again, the problem with it is that you cannot supply
it your own logging
instance, it writes it to console.log and console.error.
On Tuesday, August 7, 2012 at 7:58 PM, Tim Caswell wrote:
> Matt, David,
>
> Ignore what I said about how I use console.log, but what do you
On Tue, Aug 7, 2012 at 1:58 PM, Tim Caswell wrote:
> Matt, David,
>
> Ignore what I said about how I use console.log, but what do you think
> about TJ's debug library? To me it seems to solve your problems in a
> really elegant way.
>
Yup absolutely. And I much prefer being able to control thes
Matt, David,
Ignore what I said about how I use console.log, but what do you think
about TJ's debug library? To me it seems to solve your problems in a
really elegant way.
On Tue, Aug 7, 2012 at 12:44 PM, kuhnza wrote:
> Found this discussion on the lists from last year:
> https://groups.google
Found this discussion on the lists from last year:
https://groups.google.com/forum/?fromgroups#!topic/nodejs/YoHblrE8JJM but
it appears as though the discussion stalled.
One of the comments says it's pretty easy to re-route console output which
is true, but what do you do in the instance that
I agree - it's not right. It's very annoying to have libraries do no
logging at all. It's fine when they work... but when they go wrong I want
logs!
On Tue, Aug 7, 2012 at 1:30 PM, kuhnza wrote:
> That's my feeling also. Just did a quick survey of my node_modules folder
> and found that most lib
That's my feeling also. Just did a quick survey of my node_modules folder
and found that most libs in there simply don't perform any logging at all
(or even if they once did it's been stripped out). It's almost as though
folks have thrown it in the too hard basket and moved on. Doesn't feel
rig
I should mention that I only leave console.log statements in
production code for rare cases (like noting an http server was created
and is listening). I try to never do it in libraries I publish
because my users might not care about that information.
I like the idea of https://github.com/visionme
Nope most libs create their own logging libs or make it really hard to silence
the logs. Console log statements are a pita because as a developer you really
dont want to override build in functionality because some module is using that
as a "logger"
On 7 aug. 2012, at 18:55, kuhnza wrote:
>
Yeah that's exactly what I'm trying to avoid too Matt. I hate it when libs
indiscriminately fill up my logs with no easy way to control the
verbosity/formatting of their messages.
Is there anything like SLF4J for node? That way you could simply set the
logging implementation at the module level
On Tue, Aug 7, 2012 at 11:28 AM, Tim Caswell wrote:
> On Tue, Aug 7, 2012 at 9:54 AM, Matt wrote:
> > I prefer if you at least have a level of indirection away from
> console.log,
> > so that I can override it (or pass in a "log" function to a constructor
> of
> > some sort) without having to st
Not a bad idea. Are you aware of any other libraries that do this? Trying
to gauge how common this approach is.
On Tuesday, August 7, 2012 7:59:10 AM UTC-7, 3rdEden wrote:
>
> Just create an EventEmitter instance and emit your log events to there.
> People who then want to have logging enabled c
Thanks Tim. Based on what you're saying I'm leaning to just leaving the
console.log statements in there. Though, I'm a little unclear on how you'd
actually go about overriding console.(log|warn|error) etc. in client code.
Are you able to provide an example of how you'd do it?
Something like th
I use console.log with rconsole which adds some extra functionality
https://github.com/tblobaum/rconsole
Thomas Blobaum
On Mon, Aug 6, 2012 at 3:08 PM, kuhnza wrote:
> One thing I am keen to know right off the bat is what's the standard
> practice for logging within node libraries? Right now
On Tue, Aug 7, 2012 at 9:54 AM, Matt wrote:
> I prefer if you at least have a level of indirection away from console.log,
> so that I can override it (or pass in a "log" function to a constructor of
> some sort) without having to stomp on console.log.
The thing is, what is the purpose of console.
Just create an EventEmitter instance and emit your log events to there. People
who then want to have logging enabled can hook up their own logging library. Or
just listen to the emitted log messages using console.log
On Monday 6 August 2012 at 22:08, kuhnza wrote:
> One thing I am keen to know
I prefer if you at least have a level of indirection away from console.log,
so that I can override it (or pass in a "log" function to a constructor of
some sort) without having to stomp on console.log.
On Mon, Aug 6, 2012 at 4:08 PM, kuhnza wrote:
> One thing I am keen to know right off the bat
It's only "bad form" if it doesn't fit your use case. Every situation
is different. That's the nature of software. I tend to write mostly
small libraries and micro-sites. Winston is overkill for me. I don't
know what's best for other people because I'm not in their shoes.
On Tue, Aug 7, 2012
Interesting, thanks for that...what do you think about using something like
winston (which we currently use for all our custom stuff)? Do the same
principle still apply, or is it bad form to use third-party logging in libs?
Dave
On Monday, August 6, 2012 8:45:07 PM UTC-7, Tim Caswell wrote:
>
>
I use console.log. I override the function when I want to redirect the output.
On Mon, Aug 6, 2012 at 3:08 PM, kuhnza wrote:
> One thing I am keen to know right off the bat is what's the standard
> practice for logging within node libraries? Right now mule simply uses
> console.log but I don't t
One thing I am keen to know right off the bat is what's the standard
practice for logging within node libraries? Right now mule simply uses
console.log but I don't think this is an ideal solution.
What are others doing here?
On Monday, August 6, 2012 10:32:52 AM UTC-7, kuhnza wrote:
>
> Hey guy
21 matches
Mail list logo
