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!

[Jeff-Lewis]

@thebigredgeek Why not have that simple middleware built-in and loaded automatically by v3 to keep backwards compatibility with DEBUG_FD in v2?

I respect trying to improve this debug lib and I'm looking forward to seeing the middleware features. debug one of the most popular npm libs out there. Most of the thousands of consumers of this lib like it b/c it's dead simple and something they don't have to worry about changing.

We use DEBUG_FD and it's a valuable configuration option. It's used ~800 times in code (js and json) alone on GitHub which doesn't include all the places developers are using it only as an environment variable.

This deprecation will cause a lot of unnecessary work for a lot of people, even if it's two lines of code.

Amount of Time/Effort = (troubleshooting the change/issue + searching GitHub + reading the release notes + reading issues + adding the configuration logic to include middleware to be loaded at the proper sequence in their app + committing change + testing + releasing) X (thousands of users)

[thebigredgeek]

@Jeff-Lewis yeah that's the direction I think we were planning on going with this. Sorry for any miscommunication haha. Debug will likely come bundled with several "pre-loaded" middlewares for backwards compatibility However, still not sure whether or not this particular case should be handled within the lib. It's a lot of extra surface area to account for an edge case, especially if 2-3 months of deprecation warnings are given.

[NejcZdovc]

@TooTallNate @ORESoftware Just an update. If you are using JetBrains products: link

[luiseduardobrito]

This change is breaking all my code under WebStorm, any workaround? The @NejcZdovc link is not working.

"oops. We're sorry, but something went wrong."

[NejcZdovc]

@luiseduardobrito strange, it's working for me. Print screen of the site

[luiseduardobrito]

@NejcZdovc Really weird, tried in another network+pc and worked. But thanks for the screenshot.

Well, this may help people with the same problem, I work commercially with this tools and I can't just say to my clients that I'll wait for the WebStorm to update. So I started downgrading the debug version minor by minor until I found one that worked in my current setup.

NodeJS: 7.2
WebStorm: 2016.3.2
Debug: ^2.3.0

The warning is not displayed anymore in the console and the debug is working again. It's not ideal, but at least my dev team is working normally again. If you actually downgrade this, remember to leave a TODO in your project to upgrade it back when WebStorm 2017 is released, like I did.

[mrfelton]

This is very unfortunate change which degrades developer experience significantly by making far more complex than it was previously to route the debug messages to stderror - which is a very common thing for people to do.

In our case, the only time when we care about rerouting the messages is when we are running in a docker environment, since the logout output from docker-compose looks terrible when all of our debug messages are being printed to stderr. Previously we could just pass an env var to our docker containers to accomplish this. Now, we now have to create a wrapper library, a bunch of custom code, and alter every single place where we require in the debug module in order to get the debug output where we want it and prevent the depreciation warning.

I can understand if you want to want to change the API and depreciate the feature in a future version - that's your call (although I'd argue that hurting DX is not in the interest of the project). However, it would be good if there were a way to suppress this depreciation warning so that users of the 2.x branch can continue to use the package as they always have done without this warning constantly appearing.

[tanyaYourchuck]

@thebigredgeek My project had also used DEBUG_FD to make sure debug goes to stdout in all submodules as @wallali mentioned: 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.

Our project shows a red 'Error Occurred' message in the UI to alert users when there is output to stderr, so we intend to use stderr solely for errors. Debug logging is not something that we want to trigger this error message, its just debug info. (The warning itself is going to stderr and triggering the message.)

So I'm looking forward to a solution that allows this scenario to work.
In the meantime I'll try doing as @luiseduardobrito mentioned and downgrade the debug version to keep the desired functionality.

[mrfelton]

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!

[beeman]

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

[thebigredgeek]

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

[beeman]

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.

[pi0]

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

[bisubus]

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

[beeman]

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

[bisubus]

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

[thebigredgeek]

Hey guys, will slice a release this afternoon

[qqilihq]

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

[thebigredgeek]

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

[jy95]

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)

[bisubus]

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

[thebigredgeek]

@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

[jy95]

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