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

BUG: getFileName() on Error stack returns undefined #53

Closed
jelhan opened this issue May 21, 2021 · 2 comments
Closed

BUG: getFileName() on Error stack returns undefined #53

jelhan opened this issue May 21, 2021 · 2 comments
Labels
bug Something isn't working core tracked

Comments

@jelhan
Copy link

jelhan commented May 21, 2021

Describe the bug

new Error().stack[0].getFileName() does not return the file name but undefined. It should return the location of the file in the stack trace.

This is a common strategy to detect a caller file location. It is used in get-caller-file package, which has 25 million downloads per week accordingly to NPM. As it only requires a few lines of code it is very likely that the same technique is used even more.

It requires overloading of Error.prepareStackTrace. The implementation in get-caller-file package could be found here: https://github.com/stefanpenner/get-caller-file/blob/master/index.ts

I noticed this when trying to run ember-cli, which relies on get-caller-file.

Link to the blitz that caused the error

https://stackblitz.com/edit/node-ynwi5b?file=index.js

The following code returns undefined in Stackblitz but a file path in regular node installation.

Error.prepareStackTrace = (_, stack) => stack;
const error = Error('myError');
console.log(error.stack[0].getFileName());

You can execute by running node index.js in the blitz linked above.

As an alternative reproduction you could install get-caller-file and follow the usage example given in its documentation. It will demonstrate the same difference between regular node installation and stackblitz.

Expected behavior

It should return a file path in Stackblitz as well.

Desktop (please complete the following information):

Browser name = Chrome
Full version = 90.0.4430.212
Major version = 90
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36
performance.memory = {
totalJSHeapSize: 70345978,
usedJSHeapSize: 67259162,
jsHeapSizeLimit: 4294705152
}

Additional context

node-bindings package was facing the same issue: TooTallNate/node-bindings#29 It was fixed by this commit: TooTallNate/node-bindings@d0bd6f8

@EricSimons
Copy link
Member

Thank you so much for this detailed bug report! This should give us a running start. Will circle back with the team and get this rolling ASAP 🙏

@SamVerschueren
Copy link
Contributor

@jelhan This is now fixed 🎉 ! Thanks for reporting the issue 🙏 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working core tracked
Projects
None yet
Development

No branches or pull requests

4 participants