WIP: Make console.error and warn log a stack trace and codeframe like thrown errors do

[ychi]

Summary

Make console.error and console.warn log a stack trace like thrown errors do. As requested in this issue. Visual examples:

Error used to be like this:

It will become like this:

What warn used to look like:

And will become:

There won't be stack trace for console.log, but for consistency, it's proposed to print like this:

Instead of this:

In the original feature request, there were discussion possibility to opt out. This can be achieved by exposing a new cli option --noCodeFrame.

Closes #8819

Test plan

To pass CI, some snapshots will need to be updated.

[facebook-github-bot]

Hi @ychi!

Thank you for your pull request and welcome to our community.We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file.

In order for us to review and merge your code, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[ychi]

Hi @SimenB,

Can you take a look at the proposed output in the Summary above when you are available? I think many snapshot tests need to be updated accordingly. Please let me know which areas I can improve the code, too. Thank you very much!

[SimenB]

Oh yeah, this is looking good! I like it 👍

Let's drop the --noCodeFrame option for now - easier to add if somebody complains than removing if nobody uses it 🙂

[SimenB]

@gaearon thoughts on the output here?

[SimenB]

I think this is shaping up great @ychi! 👍 Could you add some tests, update the snapshots and add an entry to the changelog?

[SimenB]

Suggested change

	"jest-types": "^25.2.6",
	"@jest/types": "^25.3.0",

and at the top.

jest-util is also the wrong version

[ychi]

Thanks for reminding about this! dependencies in package.json should always use package name while references in tsconf.json would be relative path.

By the way, what's the reason some package names are scoped while others are not? Is it because packages published in the early days and not wanting to change package name?

[SimenB]

We got the jest namespace pretty late, and to avoid confusion we haven't renamed any packages. So in general old packages are not scoped, but new ones are scoped

[SimenB]

Thanks @ychi!

[ychi]

Oh! So much going on in one day. Thank you very much @SimenB for helping with so many things in this PR!

[kentcdodds]

Hooray!!! Thank you @ychi and @SimenB and everyone else 👏👏👏👏

[Hypnosphi]

@SimenB Sorry, but I'm not interested in those stacktraces, they only add noise in my case. Can you please reconsider adding noCodeFrame CLI and config option?

[SimenB]

We have a --noStackTrace flag, but I guess you still want the stacks for actual errors?

[Hypnosphi]

Generally, I do, but I think I'll try to live with this option a bit, thanks.

UPD: it doesn't seem to affect these console stacktraces

[SimenB]

Oh, that's a bug I think

[ychi]

I can look into the bug later today :)

[ychi]

It's because getStackTraceLines() always return at least the first line, if noCodeFrame is not explicitly set to true, this if condition will still be evaluated to true, therefore rendering the whole callsite.

One way I can see would be like this:

if ((!options.noStackTrace) && (!options.noCodeFrame)) {
    ...
}

In which --noStackTrace flag will disable code frame.

Should we go with this route? Would it be suitable for the next minor release?

[SimenB]

It should respect noStackTrace as well, yeah

[FredCoen]

hi,

in my case it adds noise as well. How do i get rid of console errors and warn?

Thanks

[kentcdodds]

If there are errors/warn in your console, you should find where those are appearing (which this new feature should help with) and why, and change your code so those don't show up. It's dangerous to simply hide errors and warnings. They probably exist for a reason and are indicative of a problem.

[FredCoen]

Im aware of that but i want to have the option to not include them in my tests. dont want to change my source code for that..

[kentcdodds]

If you want to get rid of the stack trace, then it sounds like the next version will support that with noStackTrace. Or is it that you don't want to see any of the error or warn logs at all? If that's the case, you can add this to the top of your tests or in a setupFilesAfterEnv file:

console.error = () => {}
console.warn = () => {}

I don't advise this for the reasons I mentioned earlier :)

[FredCoen]

thanks!

[Hypnosphi]

Why does it also apply to console.log and console.group?
https://github.com/facebook/jest/pull/9741/files#diff-b701d764ec6d4ad18067c4124271cd75

[ychi]

Call sites were moved to a different line for all console methods, while warn and error prints code frame and stack trace. Probably caused console.group to behave strangely, I can take a look this week.

[ychi]

Before v25.4.0, console.log and console group print like this:

After v25.4.0, they print like this:

The motivation was to make different console methods print in similar ways regardless of stack trace.

[Hypnosphi]

I'd say that this IS a stacktrace, just reduced to one line. And it definitely doesn't help readability

[oleksii-burda]

Hi guys,
Is there any updates with --noCodeFrame option?
Actually I'm not interested in stack trace for console output, but I want the stacks for actual errors, that's why I cannot use --noStackTrace flag. And I see I'm not the only one :)

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.