-
Notifications
You must be signed in to change notification settings - Fork 466
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
show line in debug() #440
Comments
That would be awesome. I don't think it's possible to update the Jest stack trace from our perspective. Jest overrides const firstUserCodeLine = new Error()
.stack
.split('\n')
.find(line => !line.includes('node_modules')) || '' Then we could log that first (and make it gray like they do). I'd be open to a PR. Also, maybe someone could do some investigation in Jest to see if there's some way to change which stack trace line gets logged with the console.log call. |
Basically what Kent is saying in #440 (comment). But I would prefer to just slice out our particular frame instead of relying on n_m layout. |
Hello, I'd like to take a look at this. @eps1lon I've thought about the extraction of a particular frame, however, since
|
Maybe this is naive but I literally meant .slice(). Does transpiling or dev vs prod affect that? |
Sorry, I'm not sure if I understand what you mean by "affect that". Do you mean the fact that we can't differentiate between client and library code without relying on |
You know... If this happens: jestjs/jest#8819 Then we could just switch to |
Hi! |
Hello, I’d love to keep working on this now that the jest issue is solved. I’ll take a look these next couple of days. |
Here are the 2 alternatives I've found to implement this Option AWe use the new console.warn or console.error from jest, which contains the call stack. Here's a sample: The problem with this approach is that it's verbose and the stack frame we care about isn't obvious (here it's src/app.test.js:22:12). Option BIf we do the heavy lifting ourselves with something like this commit. Unfortunately, the line number doesn't play well with transpilers so it can easily be wrong. I tested this with a new babel-jest project and it had this issue. Of course, I lean towards the first option, but for me it adds too much noise so I'd prefer not to have it. If we find a way around the second option's issue I'd prefer that one. Would love to know your thoughts @eps1lon @kentcdodds |
either option is definitely a huge improvement over current situation. having said that, if i had to choose, i probably would prefer option 2, but if the reasons you mention are problematic, i'd be ok w/ option 1. but just curious, is there an option 3... i.e. option 1 + option 2 both? |
I'd say they're mutually exclusive. If the second one worked without additional work (e.g. babel config), then the first one wouldn't be needed at all. 🆘 If anyone knows of an easy way to make option 2 work (a.k.a. how to configure babel and typescript to show the correct line for ES6 in a jest environment), we could follow that one. I might be missing something. I'll wait a bit (1-2 days) and if there's no other suggestion I'll work on the first option :) |
Works for me. option 1 is a welcome improvement to me. |
I wonder if we could print the stack trace and code frame ourselves. I'm pretty sure we could get the stack trace and then hand that to some module to retrieve the code frame which we could log. Want to investigate that? |
I ended up going with Kent's approach on this one. Just had to add a bit of coloring and it just shows the line where |
🎉 This issue has been resolved in version 7.24.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Describe the feature you'd like:
I'm not sure if this is even possible, but figured I'd throw it out there. When I use
console.log('foo')
the console will include the line number where the console log was made. However, when using debug() it's always pointing to the line in dom-testing-library (see screenshot).I'm not even sure if its possible to do this, but it would be so great if instead showed the line in my code where debug was called.
Suggested implementation:
Describe alternatives you've considered:
Teachability, Documentation, Adoption, Migration Strategy:
The text was updated successfully, but these errors were encountered: