Node: Stack Trace on Depreciation Warnings

[bcomnes]

• Version: v7.0.0
• Platform: Darwin bret-mbr.local 16.1.0 Darwin Kernel Version 16.1.0: Thu Oct 13 21:26:57 PDT 2016; root:xnu-3789.21.3~60/RELEASE_X86_64 x86_64
• Subsystem:

It would be handy if warnings provided a stack trace when thrown, so that I can track down the source of the warning and possibly PR upstream fixes. Right now, a lot of modules are throwing the missing new Buffer warning, but don't provide any hints at where to look to make the fix.

@mikeal mentioned that this should be pretty easy to do possibly: https://twitter.com/mikeal/status/796072579563851776

[sam-github]

Isn't this exactly what https://nodejs.org/api/cli.html#cli_trace_warnings does?

[bcomnes]

Yeah that would be handy I presume. I don't trace warnings very often so I wasn't aware of it. 😅 Still, is it possible to include a file and a line in the default warning message?

[bcomnes]

For example, this is pretty bad UX, and probably a common example of where people run into this issue:

bret-mbr:bret.io bret$ browserify src/index.js -o bundle.js --trace-warnings
(node:39223) DeprecationWarning: Using Buffer without `new` will soon stop working. Use `new Buffer()`, or preferably `Buffer.from()`, `Buffer.allocUnsafe()` or `Buffer.alloc()` instead.

[bnoordhuis]

@bcomnes --trace-deprecation

(As to why there are two flags: I don't know.)

[jasnell]

There are two flags because --trace-deprecation was already there and already part of people's workflows. It didn't make sense to break that. --trace-warnings is more general to support all types of warnings, not just deprecations.

[bcomnes]

Still not working the way I would expect:

Heres running a browserify test:

bret-mbr:test bret$ node glob.js --trace-warnings --trace-deprecation
TAP version 13
    # Subtest: glob
    1..6
(node:39743) DeprecationWarning: Using Buffer without `new` will soon stop working. Use `new Buffer()`, or preferably `Buffer.from()`, `Buffer.allocUnsafe()` or `Buffer.alloc()` instead.
    ok 1 - should be equal
    ok 2 - should be equal
    ok 3 - should be equal
    ok 4 - should be equal
    ok 5 - should be equal
    ok 6 - should be equal
ok 1 - glob # time=276.824ms

1..1
# time=299.257ms

Am I doing it wrong?

[evanlucas]

try passing the flags before the file

[jasnell]

For instance:

$ ./node --trace-deprecation
> Buffer(1)
<Buffer 04>
> (node:40756) DeprecationWarning: Using Buffer without `new` will soon stop working. Use `new Buffer()`, or preferably `Buffer.from()`, `Buffer.allocUnsafe()` or `Buffer.alloc()` instead.
    at Buffer (buffer.js:79:13)
    at repl:1:1
    at sigintHandlersWrap (vm.js:22:35)
    at sigintHandlersWrap (vm.js:96:12)
    at ContextifyScript.Script.runInThisContext (vm.js:21:12)
    at REPLServer.defaultEval (repl.js:313:29)
    at bound (domain.js:280:14)
    at REPLServer.runBound [as eval] (domain.js:293:12)
    at REPLServer.onLine (repl.js:513:10)
    at emitOne (events.js:101:20)
.exit
$ ./node --trace-warnings
> Buffer(1)
<Buffer 04>
> (node:40780) DeprecationWarning: Using Buffer without `new` will soon stop working. Use `new Buffer()`, or preferably `Buffer.from()`, `Buffer.allocUnsafe()` or `Buffer.alloc()` instead.
    at Buffer (buffer.js:79:13)
    at repl:1:1
    at sigintHandlersWrap (vm.js:22:35)
    at sigintHandlersWrap (vm.js:96:12)
    at ContextifyScript.Script.runInThisContext (vm.js:21:12)
    at REPLServer.defaultEval (repl.js:313:29)
    at bound (domain.js:280:14)
    at REPLServer.runBound [as eval] (domain.js:293:12)
    at REPLServer.onLine (repl.js:513:10)
    at emitOne (events.js:101:20)

[jasnell]

And you only need one of the flags, not both. --trace-deprecations will show the stack trace _only_ for DeprecationWarning. --trace-warnings will show the stack trace for _all_ warning types.

[bcomnes]

Aw sorry, the test was using child-process. I'm seriously not trying to be dense here 😬

https://github.com/substack/node-browserify/blob/master/test/glob.js

so even passing the arg first doesn't work, for obvious reasons.

$ node --trace-warnings glob.js
TAP version 13
    # Subtest: glob
    1..6
(node:39800) DeprecationWarning: Using Buffer without `new` will soon stop working. Use `new Buffer()`, or preferably `Buffer.from()`, `Buffer.allocUnsafe()` or `Buffer.alloc()` instead.
    ok 1 - should be equal
    ok 2 - should be equal
    ok 3 - should be equal
    ok 4 - should be equal
    ok 5 - should be equal
    ok 6 - should be equal
ok 1 - glob # time=281.214ms

1..1
# time=306.824ms

Is there an ENV var I can use to pry into tooling problems like this? Could a more useful breadcrumb be provided in the default warning?

[addaleax]

I think tap has a --node-arg=… option that you could use here?

[bcomnes]

I think tap has a --node-arg=… option that you could use here?

Its using tape, but I'll look for a similar option.

Let me reframe the problem slightly:

Im using a common node tool (e.g. browserify but it could be whatever), that begins to throw a warning due to a new node release. I have a few free minutes and want to dig into the source of the warning. Whats the easiest way to trace the source of that warning?

I could be naive here, but it seems like there should be an easy and general way to solve this. Node args unfortunately aren't that general in situations like this. Env vars perhaps? Simply providing the path to the offending file in the default warning message (is that even possible)?

[sam-github]

It might be hard. Its possible to walk the stack upwards, but knowing the first file/line that is "not node core" isn't necessarily easy. You can manually count, but if you are emitting the deprecation from code that can be reached by paths of different depths, its not pre-known how far up the stack the user code is.

I also feel the env var vs CLI option pain, there is no fix for this ATM. I am trying to make time to implement a NODEOPT env variable, so all (reasonable) CLI options can also be specified by env var, but for now, you'll need to use the CLI. For tape, you might be able to do node --trace-warnings $(which tape) ... or something of the like.

[bcomnes]

A NODEOPT alternative sounds like it might be general enough, and relatively easy to use. Happy to hear its in the works.

The suggestions are also helpful to the random cases that I'm looking into thank you.

Should I close this, reference an existing issue, leave open?

[sam-github]

I dunno, how dissatisfied are you? Seems like its working as intended, but also slightly awkward. If more people hate it they will post bugs, and then someone might try and figure out a better way, but it does look like what you want is possible ATM, with the CLI arguments.

[bcomnes]

@sam-github Yes, working as intended, especially for library use. For node programs where passing the node argument passing is obfuscated, an ENV interface that you mentioned would improve the UX imo.

Is there an open issue or PR for that work I can reference here then close this one?

[jasnell]

@bcomnes no PR that I'm aware of.

[bcomnes]

One other approach I realized is just modifying the shebang with the desired flags. Good enough for me.