debug.enable() NOT dynamic

[KevinAst]

I am new to debug logger and I thank you for your awesome utility.

In my experience, using debug.enable('myProj:myModule:myFn') does NOT dynamically impact the logging filters in the current process (in either the browser or node). It merely resets the DEBUG env var (or the browser's localStorage.debug). The process must then be re-started for it to take effect.

I am using the latest 4.3.3 release.

I must be doing something wrong, as the README docs clearly state that enable() dynamically resets the filter.

The ability to dynamically change the logging filters (without restarting the process) is a crucial feature for production code, especially in a node/server environment.

I have searched both the debug project issues -and- stackoverflow with no luck. I did find a number of enable() issues, but none that seemed to match my problem.

One thing I considered is I am creating my log instances in a "module scope", so my probes live a lifetime in the process. Is this an incorrect usage? Should I be creating log instances in a function scope, so they are re-created on each function invocation? I tried a quick test of this, and it seemed the results were the same (still no dynamic behavior).

From an application perspective, this feature would seem to be very rudimentary ... so as I stated, I must be doing something wrong.

Any help would be greatly appreciated.

[Qix-]

It might be the case, honestly. Using debug.enable() is very highly discouraged and hasn't worked "correctly" since it was written. I know that's probably not the answer you want to hear.

You should be using the DEBUG environment variable whenever possible. Setting individual debugger enabled properties should also work correctly. The top-level debug.enable() function is a mine field and has multiple documented issues.

From an application perspective, this feature would seem to be very rudimentary ... so as I stated, I must be doing something wrong.

One of those situations that seems simple until you go to implement it and try to make it performant and realize you're slowing everyone down when you try to simplify things.

[KevinAst]

Thanks for your quick response @qix.

Please Note that since my original post had not been responded to, I re-worded it (removing some off-topic questions), and updated it with my latest results (I actually got it working)!

• I may ask my off-topic questions on a new issue.

• I would really like your thoughts on the Mine Field Future?.

FYI: When I used the term "rudimentary" (above), I was not implying that it was easy to implement, rather that it's usage was easy (not understanding how I messed it up :-)

Background

Certainly in a development environment it is feasible to use the DEBUG env var. However I am working on a server-based administrative utility that provides the ability to dynamically alter the filters in a production deployment (without re-starting the server). In this context, the debug.enable() feature is crucial in diagnosing unexpected conditions in production.

Thoughts?

Regarding My Problem - NOW FIXED!

For what it is worth, I just now resolved my problem and it is working very well :-)

| debug.enable(filter) now works BOTH on my client (a Svelte web-app) and my server (a Node app).

As I mentioned, I am working with a MonoRepo. I analyzed it to insure there were consistent top-level npm versions of the debug lib (across all the packages of my MonoRepo). In my case I found a "rouge" top-level npm debug lib installed on my server that was sorely out-of-date. I'm not exactly sure where it came from (I did not install it). I suspect it originated from one of my dev-dependencies that in-turn uses the debug lib.

Bottom line is, once I explicitly installed the latest debug lib in all my MonoRepo packages, everything started working (both client and server). I can even enable logs of other packages (by using the "*" filter) ... for example socket.io.

Mine Field Future?

Regarding the debug.enable() "mine field", are there plans to shore shore this up (possibly in a major release)? As I mentioned, this is a crucial feature for projects that are retaining their logging probes in production.

Thoughts?

Thanks

Thanks in advance, for your time and response.

[Qix-]

are there plans to shore shore this up

Yes, quite a few issues are open about it. Checked the pin roadmap issue #656 which mentions the various pieces of the .enable() puzzle.

Unfortunately I'm all too familiar with the problems of .enable(), so there's not much else to be said here. It's a known problem, and there are plans to fix it. Just a matter of when. Not much I can do here but to direct you to the other issues, sorry about that.