Repository navigation
"Just My Code" for stack traces? #20505
Description
Activity
Seems pretty well suited to the user-land, no? Just use a custom
Error.prepareStackTracethat filters out Node.js core modules & node_modules code. There are some edge cases but I don't think that's a good reason to make it be a part of the core.(Can also do all kinds of other neat things with the API https://github.com/v8/v8/wiki/Stack-Trace-API)
One argument in favor is that only core can disambiguate stack frames with 100% certainty.
vm.runInThisContext('throw new TypeError()', {filename:'vm.js'})throws an exception that looks like it comes from the vm module, but doesn't, and there's really no way for a user land hook to tell.That said, I don't necessarily think hiding stack frames is a good idea. I can quickly see that turning into a bigger hindrance than a help, with people filing bug reports with unhelpful stack traces. Getting a good bug report is already more the exception than the norm, in this day and age.
Reacted by Benjamin Gruenbaum, mary marchini, MBetters, Denys Otrishko and John Shinemaybe a plugin that make colors of files in node_modules gray and less contrast so you can see what file are yours
If it can be done reasonably well I think this would be excellent to have but I definitely share @bnoordhuis' concern around it. It wouldn't hurt to have some non-committal experimentation around it.
so what im saying wont hide it, but only visually color it differently in terminal.
i created a simple script that accomplishes what i was thinking....
I simply put it in main app.js fileconst colors = require('colors'); Error.prepareStackTrace = (err, arr) => { let lines = err.stack.split('\n'); lines = lines.map(x => x.includes('node_modules') ? colors.grey(x) : x); lines = lines.join('\n'); err.stack = lines; };then in one of my routes of app
throw new Error('test');result ....
Reacted by Kyle Mitofsky, Sage Pacheco, Sanjar Afaq and Tal JacobProblem with just different Coloring is when you use SDKs which transfer the flow of control a lot.
I use the
aws-sdka lot and the stack traces there are not useful because it is filled with the stack of the internal function calls, hiding frames fromnode_modulesoption will help a lot in this case.didn't explain how coloring won't help sdk traces which live in node_modules...
Just realize that we have a default
Error.stackTraceLimit = 10, so unless users set this to a higher value, many of our internal stack frames are probably not going to be visible to them anyway if their code throws in a sufficiently deep call stack.Another idea would be to exclude all the stack frames up to the first frame of user code (on master it's usually
Module._compileand 8 frames below)Reacted by Benjamin Gruenbaum, techsin, John Shine and Chris DeacyThis is partially fixed since a while. Using
console.logorutil.inspecton errors marks Node.js stack frames grey and adds an underscore tonode_modulesnames. We could go ahead and add a color to node_modules frames but not everyone wanted that. Should this stay open or shall we consider it as solved?Reacted by Rich Trott and Kyle MitofskyI'd say let's consider it solved. If someone wishes to make further enhancements, a PR with a concrete proposal would be ideal. Closing
@joyeecheung
Error.stackTraceLimitdoesn't solve the issue, it just changes the number of lines it prints.For example in the following stack, only two lines (related to file
prepareServer) were related to files I developed (followed by<===). The others for me are noiseError at buildAdministrationsObject (/home/joao/dev/geoptapi/prepareServer.js:350:11) <=== at /home/joao/dev/geoptapi/node_modules/async/dist/async.js:3638:28 at replenish (/home/joao/dev/geoptapi/node_modules/async/dist/async.js:443:21) at iterateeCallback (/home/joao/dev/geoptapi/node_modules/async/dist/async.js:427:21) at /home/joao/dev/geoptapi/node_modules/async/dist/async.js:324:20 at /home/joao/dev/geoptapi/node_modules/async/dist/async.js:3643:17 at /home/joao/dev/geoptapi/prepareServer.js:158:7 <=== at wrapper (/home/joao/dev/geoptapi/node_modules/async/dist/async.js:271:20) at iterateeCallback (/home/joao/dev/geoptapi/node_modules/async/dist/async.js:424:28) at /home/joao/dev/geoptapi/node_modules/async/dist/async.js:324:20If I change
Error.stackTraceLimit = 6for example I will miss my second line.I just want to filter out lines including
node_modulesCame up with this solution that strips out any line with
/node_modules/or\node_modules\const stripedStack = (new Error().stack).replace(/^.*[\\/]node_modules[\\/].*$/gm, '').replace(/\n+/g, '\n') console.error(stripedStack)
Now as I wanted :)
Error at readShapefile (/home/joao/dev/geoptapi/prepareServer.js:106:16) at /home/joao/dev/geoptapi/prepareServer.js:100:7what do you think @jasnell ?
I edited @techsin comment with the following:
const colors = require('colors'); Error.prepareStackTrace = (err) => { let lines = err.stack.split('\n'); lines = lines.map((x) => { return x.includes('node_modules') ? colors.grey(x) : x; }); lines = lines.map((x) => { return x.includes('(node:') ? colors.grey(x) : x; }); lines = lines.join('\n'); return lines; };
Throwing a raw idea out there:
I just saw this question where a user was confused about a stack trace they got when using puppeteer:
The point is, the first few stack frames are irrelevant to the user. If the first stack frame showed the part in their code that caused the error it would have been a lot more useful.
I'm wondering if we can improve the debugging experience of users by giving them "Just My Code"
Just My Code
Node could expose a "Just My Code" exception mode similar to the way stacks work in the Chrome devtools. Running Node with the flag would hide any frames from
node_modulesfolder.Thoughts?