Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I think this is a fix for #710.
I've confirmed that the issue there is a regression introduced in #578. That PR was a fix for #574, which was an error that happened with certain weird objects that don't have a constructor: #574 (comment).
The fix was in
formatObject()
, which is a function in the mock console that takes an object to be logged and tests to see if it's any of various types that want special-case formatting. If the object isn't one of these types, thenformatObject()
just returns the original object.The resolution for #574 was to add another special case for weird objects that don't have a constructor or a prototype, (not sure why the non-prototype bit is important) that formats these weird objects.
However, it looks like the condition to check that had an error:
First because this is
||
it will be true if either condition is true, which isn't what we want (at least according to the description in the issue). But also, I thinkobjectName
isn't necessarily the object, it's the result of calling:So in the case of the
const
example,input
is aTypeError
object, soobjectName
is a string"TypeError"
. And then it doesn't have a prototype, so we run that special-case code, which gives us"Object { }"
.What we want to happen here, I think, and what used to happen, is to skip all the special cases in this function and return
input
.I'm guessing this will happen not only for
TypeError
but for many other types that didn't match any of the other special cases, and they will just fall through into this one.So, I've tightened up that conditional so it's only going to catch these weird types.
I have checked that this fixes the
const
case and the others listed in #710 (comment), and doesn't regress #574, and have tried a few other examples. But, this is tricky code as we've seen. I don't know if we have good tests for it, but it certainly needs careful review.