DEBUG_FD warning (from this project?)

[ORESoftware]

I have process.on('warning') logging stuff in a project, I got this today, brand new:

(node:29558) DeprecationWarning: `DEBUG_FD` is deprecated. Override `debug.log` if you want to use a different log function (https://git.io/vMUyr)

  => Live-Mutex warning =>  DeprecationWarning: `DEBUG_FD` is deprecated. Override `debug.log` if you want to use a different log function (https://git.io/vMUyr)
    at Object.<anonymous> (/home/oleg/WebstormProjects/oresoftware/observable-persistent-queue/node_modules/debug/src/node.js:62:148)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/home/oleg/WebstormProjects/oresoftware/observable-persistent-queue/node_modules/debug/src/index.js:9:20)
    at Module._compile (module.js:571:32) 

the git.io link links to this project, but otherwise I am not sure what to do. Can you help? thanks

[TooTallNate]

DEBUG_FD is the environment variable. Do you have that set in your project? If so, how are you using it?

[ORESoftware]

I don't set that variable..hmm, do native addons set the variable somehow? weird!

[thebigredgeek]

The variable is being set somewhere. It will continue working until 3.0. We added the deprecation warning to let everyone know that it will no longer be supported after the v3 release :)

[ORESoftware]

@TooTallNate @thebigredgeek I think Webstorm sets it, when you use the Webstorm runner to execute a Node.js file

[thebigredgeek]

Ahhh shit haha. That's no good. Wonder if they have an issues list somewhere on github?

[ORESoftware]

I have never seen it before, so it might not be Webstorm, but that's my best guess right now, and it's fairly plausible given the evidence.

[wallali]

Hello,
I think the DEBUG_FD variable was very useful to me. Is there a reason to deprecate it?

I run my apps on IBM Bluemix and when running in that environment I had the DEBUG_FD set to 1 so that my logs would NOT go into stderr (which is reserved for recording critical failures on bluemix). While running locally I leave it unset.

Hence DEBUG_FD allows the log location to be switched by environment. I believe the suggestion to override debug.log is not the same this because:

• it is not easily controlled by an environment variable without writing even more code.
• it requires writing code for something that DEBUG_FD accomplished very easily where the output stream to use needs to be switched not the log function itself.

[thebigredgeek]

@wallali with V3 we will introduce log middleware that will allow you to "replace" the normal output mechanism and redirect logs to wherever you want (stdout, stderr, logstash, etc). So hang tight!

[sulliwane]

Hello, I also see this warning. I explicitly set env DEBUG_FD=1, because I don't want the default debug() to print to stderr.

So right now I'm doing:

const debug = createDebug('app'); // default debug() print to stdout, pm2 will save stdout to .log files
const logError = createDebug('app:error');
logError.log = console.error.bind(console); // logError() now prints to stderr, pm2 will save stderr to .error file

As I understand, to comply with the new version of debug I need to remove my env var DEBUG_FD=1. But then, how can I alter in ONE COMMAND, the default output of debug() ?

I'd like to remove these warnings...Many thanks!

[wallali]

@thebigredgeek Another very important use of DEBUG_FD I realise now is that it automatically redirects output from all of my modules and any modules I depend on that also use debug to stdout.

If I have to write code to do the redirect two problems arise:

• The boiler-plate code that does the redirect to stdout needs to be written in each file that I require('debug');
• Modules I depend on who also internally use debug whose code I do not control keep outputting to stderr and I cannot redirect them to stdout.

The advantage of DEBUG_FD (or a similar environment variable) is that it allows the stderr/stdout choice to be made later at the time of module usage by the clients of my module rather than at the time of module development.

[TooTallNate]

The reason it was deprecated was because of the way that we were creating a WritableStream to that file descriptor was non-standard for Node.js and using some undocumented APIs. See #280 for more details.

One thing we could do is retain backwards compat for DEBUG_FD when the value is 1 or 2 only (since that's just process.stdout and process.stderr respectively).

[wallali]

One thing we could do is retain backwards compat for DEBUG_FD when the value is 1 or 2 only (since that's just process.stdout and process.stderr respectively).

@TooTallNate I like this idea.

[thebigredgeek]

We should provide a "global" middleware hook in v3, such as:

import debug, { OutputMiddleware } from 'debug';

debug.replace(OutputMiddleware, (data, next) => { process.stdout.write(data); next(); })

[thebigredgeek]

I am really hoping we can reduce the swiss army knife API that we currently support. Using middleware makes it easy for people to continue using existing environment variables by adding simple functions for output parsing. I think that will be the ideal solution on both sides.

[sulliwane]

@thebigredgeek If the middleware example you provided is meant to be set only once then this looks good to me. Is it possible to use this middleware function with current version 2.6 ?

If not, is there a way to let the warning go away? Thanks!