DEBUG_FD warning (from this project?)

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

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

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

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 :)

@TooTallNate

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

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

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.

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.

@wallali

@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!

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!

@thebigredgeek

@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.

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).

@TooTallNate

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.

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(); })

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.

@thebigredgeek

@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!

@thebigredgeek

Awesome. Thank you for addressing this @thebigredgeek

It would be good to get a new patch release cut that includes this fix so that everyone who has been bugged by it can move on and forget about it at last!

@pi0

@pi0 thanks for fixing, @thebigredgeek thanks for merging. A release would indeed be great.

I need to test a bit before releasing. Will do so when I have some free time. Currently slammed at work

@thebigredgeek

I need to test a bit before releasing. Will do so when I have some free time. Currently slammed at work

@thebigredgeek would it be possible to publish a canary release to npm? I'm more than happy to test it as I've been seeing this message the whole day for a few weeks now.

Thanks for considering.

@thebigredgeek

@thebigredgeek Please review & release 😭😭I (& probably many other people) are suffering that warn every day, every build, every reload... Please keep your awesome project awesome :)

I've released a package to prevent this, https://github.com/ex-machine/debug-fd-deprecated

It will take care of deprecation warnings for some time (some packages were already hard-coded to debug@2.6.0).

@bisubus

@bisubus I've considered doing the same though the problem is that you now have to go through your app and update all import statements, only to revert it later.

In a small app this is not a big problem, in a large app more so.

So a release will be very well received, the patch has been merged two weeks ago now...

@beeman

@beeman I've managed to do this by patching util.deprecate. This should be done once per app instance, as early as possible, because there are too many third-party packages that depend on debug. I've done this in polyfills.js.

Hey guys, will slice a release this afternoon

@thebigredgeek

Hey @thebigredgeek, is this release already out? Looking forward!

2.6.1 is now live. Sorry for the long delay. Been super crushed at work haha

Euh, I still got this issue when starting tests in webstorm :

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

@jy95

@jy95 You likely got a dependency that depends on 2.6.0. Any way, see this if you need a hotfix.

@jy95

@jy95 run npm ls debug. You'll see any duplicitous versions that might be installed. If you find any that depend on 2.6.0, submit an issue on their github repos and link this issue to the issue. I'll chime in on the projects and see if I can help push them along to the latest versions

@thebigredgeek

@thebigredgeek Thanks. It seems it is the "eslint"@3.19 package that use debug@2.6.6.
. An little npm update seem to calm this error message ...

Navigation Menu

Repository navigation

DEBUG_FD warning (from this project?) #410

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

DEBUG_FD warning (from this project?) #410

Description

Activity

TooTallNate commented on Jan 4, 2017

ORESoftware commented on Jan 4, 2017

thebigredgeek commented on Jan 4, 2017

ORESoftware commented on Jan 4, 2017

thebigredgeek commented on Jan 4, 2017

ORESoftware commented on Jan 4, 2017

wallali commented on Jan 4, 2017

thebigredgeek commented on Jan 4, 2017

sulliwane commented on Jan 5, 2017

wallali commented on Jan 5, 2017

TooTallNate commented on Jan 5, 2017

wallali commented on Jan 5, 2017

thebigredgeek commented on Jan 5, 2017

thebigredgeek commented on Jan 5, 2017

sulliwane commented on Jan 6, 2017

11 remaining items

mrfelton commented on Jan 24, 2017

beeman commented on Jan 24, 2017

thebigredgeek commented on Jan 24, 2017

beeman commented on Feb 1, 2017

pi0 commented on Feb 2, 2017

bisubus commented on Feb 5, 2017

beeman commented on Feb 5, 2017

bisubus commented on Feb 5, 2017

thebigredgeek commented on Feb 7, 2017

qqilihq commented on Feb 10, 2017

thebigredgeek commented on Feb 10, 2017

jy95 commented on May 11, 2017

bisubus commented on May 12, 2017

thebigredgeek commented on May 12, 2017

jy95 commented on May 12, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions