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

display node.js version (process.version) at the end of stacktraces #29731

Closed
ORESoftware opened this issue Sep 27, 2019 · 15 comments
Closed

display node.js version (process.version) at the end of stacktraces #29731

ORESoftware opened this issue Sep 27, 2019 · 15 comments
Labels
errors Issues and PRs related to JavaScript errors originated in Node.js core. feature request Issues that request new features to be added to Node.js.

Comments

@ORESoftware
Copy link
Contributor

This could be added with a flag, and later turned off with a flag if you don't want to see it.

with this in mind:
nodejs/help#2204

the current stacktrace is:

SyntaxError: Invalid or unexpected token
at Module._compile (internal/modules/cjs/loader.js:723:23)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)
at startup (internal/bootstrap/node.js:283:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

it would be interesting if it looked like:

SyntaxError: Invalid or unexpected token
at Module._compile (internal/modules/cjs/loader.js:723:23)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)
at startup (internal/bootstrap/node.js:283:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)
via node.js version: 12.3.4

or whatever

just an idea, not sure if it's possible/desirable to implement

@boneskull
Copy link
Contributor

@ORESoftware Is there a precedent for this anywhere?

@ORESoftware
Copy link
Contributor Author

not sure if there is a precedent but it would be a nice feature. it does make stack traces noisier though. so maybe a flag to switch it on/off.

@mhdawson
Copy link
Member

If you enable --experimental-report --report-uncaught-exception you would get the node version and much more. Having said that it's still and interesting idea.

@Fishrock123
Copy link
Contributor

I dunno, if you don't know what node binary you are running that seems like an issue in itself not really solvable by us.

@ORESoftware
Copy link
Contributor Author

@Fishrock123 it's primarily for helping people online when they post stack traces, but even at work I switch between node.js versions and don't always recall or consider which one I am using etc.

@gireeshpunathil
Copy link
Member

IMO printing the node.js version in stack trace is good, although it addresses a minimal subset of problem determination through FFDC (first failure data capture). For example, on a similar ground I can see that openssl version, javascript heap size , command line that was passed etc. can also solve another class of problems. So diagnostic report looks to be the right approach here?

@ORESoftware
Copy link
Contributor Author

this is a very useful feature, useful for a thousand github issues, like this one most likely: ORESoftware/live-mutex#92 (comment)

@juanarbol
Copy link
Member

@ORESoftware Diagnostic report is now stable, you should consider using it for this case.

@ORESoftware
Copy link
Contributor Author

the user case here is for stack traces in general, so you dont have to ask "what node version are you on?" sometimes its easy to forget to ask

@targos targos added errors Issues and PRs related to JavaScript errors originated in Node.js core. feature request Issues that request new features to be added to Node.js. labels Dec 26, 2020
@theoludwig
Copy link
Contributor

the user case here is for stack traces in general, so you dont have to ask "what node version are you on?" sometimes its easy to forget to ask

Indeed, I think it is a nice thing to have the Node.js version at the end of stacktraces, I opened a PR to implement that: #38332

@Fishrock123
Copy link
Contributor

My stance on this has changed. Print that stuff. Not that i have any say here, but hey. (Also, unsubscribing.)

@danielleadams
Copy link
Contributor

danielleadams commented Jun 9, 2021

Maybe a topic for a different issue, but does it make sense to include a link to the API documentation for the version too? It may bloat the stack trace even more, but discoverability of API docs for different versions can be confusing and it could help remove a couple steps before opening an Issue or SO question. (ie. https://nodejs.org/dist/v14.17.0/docs/api/)

@mhdawson
Copy link
Member

mhdawson commented Jun 9, 2021

@danielleadams I'd be worried that that link might change, we currently have nodejs.org and nodejs.dev and its not impossible that we might change doc structure. Having the version should make it relatively easy to find the right version of the API docs.

@ORESoftware
Copy link
Contributor Author

was this implemented or is it still only behind a node flag?

@theoludwig
Copy link
Contributor

was this implemented or is it still only behind a node flag?

Yes it is available on Node.js >= v17.0.0, no flag required (but you can disable it with a flag). @ORESoftware

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
errors Issues and PRs related to JavaScript errors originated in Node.js core. feature request Issues that request new features to be added to Node.js.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants