Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DEBUG_FD warning (from this project?) #410

Closed
ORESoftware opened this issue Jan 4, 2017 · 38 comments
Closed

DEBUG_FD warning (from this project?) #410

ORESoftware opened this issue Jan 4, 2017 · 38 comments

Comments

@ORESoftware
Copy link

ORESoftware commented Jan 4, 2017

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
Copy link
Contributor

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

@ORESoftware
Copy link
Author

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

@thebigredgeek
Copy link
Contributor

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
Copy link
Author

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

@thebigredgeek
Copy link
Contributor

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

@ORESoftware
Copy link
Author

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
Copy link

wallali commented Jan 4, 2017

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
Copy link
Contributor

@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
Copy link

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
Copy link

wallali commented Jan 5, 2017

@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
Copy link
Contributor

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
Copy link

wallali commented Jan 5, 2017

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

@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
Copy link

Jeff-Lewis commented Jan 6, 2017

@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
Copy link
Contributor

thebigredgeek commented Jan 11, 2017

@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
Copy link

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

@luiseduardobrito
Copy link

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
Copy link

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

image

@luiseduardobrito
Copy link

luiseduardobrito commented Jan 12, 2017

@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
Copy link

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
Copy link

tanyaYourchuck commented Jan 19, 2017

@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
Copy link

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
Copy link

beeman commented Jan 24, 2017

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

@thebigredgeek
Copy link
Contributor

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

@beeman
Copy link

beeman commented Feb 1, 2017

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
Copy link
Contributor

pi0 commented Feb 2, 2017

@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
Copy link

bisubus commented Feb 5, 2017

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
Copy link

beeman commented Feb 5, 2017

@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
Copy link

bisubus commented Feb 5, 2017

@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
Copy link
Contributor

Hey guys, will slice a release this afternoon

@qqilihq
Copy link

qqilihq commented Feb 10, 2017

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

@thebigredgeek
Copy link
Contributor

thebigredgeek commented Feb 10, 2017

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

@jy95
Copy link

jy95 commented May 11, 2017

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
Copy link

bisubus commented May 12, 2017

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

@thebigredgeek
Copy link
Contributor

thebigredgeek commented May 12, 2017

@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
Copy link

jy95 commented May 12, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests