-
Notifications
You must be signed in to change notification settings - Fork 30k
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
assert: add rawMessage
to error messages
#19723
Conversation
lib/internal/errors.js
Outdated
@@ -386,6 +386,7 @@ class AssertionError extends Error { | |||
this.actual = actual; | |||
this.expected = expected; | |||
this.operator = operator; | |||
this.rawMessage = lazyInternalUtil().removeColors(this.message); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like this could be a prototype getter, for performance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm... I'm not sure about this. Once we get a bit further along with assigning the error codes to the errors, I'd like to pursue adding these kinds of non-standard properties off a new Error.prototype.info
bucket rather than directly off the Error
object. "Why?", you may ask? The reason is to give a consistent common location for non-standard Additional Stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is, to say, if this PR, for instance, added an info
property with the actual
, expected
, operator
and rawMessage
properties to an Error.prototype.info
and made the existing properties directly off the Error
object into aliases that we could deprecate in 11.0.0, I'd be much happier with this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That (having access to the properties you mention) would actually be even better for our use case in Jest of transparently supporting assert
but making it look native to Jest, so huge 👍 to that!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jasnell I guess the reason to have all additional properties on a single property is that it might conflict less with properties added else wise? I do not think that we should move all properties to a single property but we do lack documentation and more important out of my perspective: we should definitely export all our errors. That way the users could easily identify errors from Node.js core by just checking for being of the NodeError class. I think that is actually a better way to solve this problem than by moving everything to info
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it to a prototype getter and setter.
Thanks for doing this! 🙂 Will make interop much cleaner |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
@SimenB I am not exactly sure in what way it will actually improve the interop. The messages could change due to being further improved and I strongly advice against relying on the error message by simply parsing it. If you want to verify input with a assert error message there is actually a good way to do that as described here: https://github.com/nodejs/node/pull/19724/files |
It'll improve it in that it allows us to not have to strip away redundant (as we have our own way of conveying the same thing) information. Some combination of We have a way of separating the |
I am still not sure I can follow. Let's say we have the following: assert.strict.deepStrictEqual([1,1,1,1,1,2,2,2,2], [1,1,1,1,1,2,2,2])
// AssertionError [ERR_ASSERTION]: Input A expected to deepStrictEqual input B:
// + expected - actual ... Lines skipped
// [
// 1,
// ...
// 1,
// - 2,
// 2,
// ...
// 2
// ] This would include colors. If the default util.inspect settings are set to contain colors, the numbers will all also be colored. But what can you do with this message? Don't you generate a complete new message in Jest? And what would happen if the message format is slightly changed again? |
@BridgeAR Side question: This is labeled I don’t think it’s a terrible thing if it doesn’t happen in this PR, but as I understand it these properties are intended for public consumption, so we probably should document them eventually, right? |
We keep the original message (but tweak the stack) in addition to a custom message. See https://github.com/facebook/jest/blob/1eb02fd41ad6840350a5b2c0636151e2da8bcd8b/integration-tests/__tests__/__snapshots__/failures.test.js.snap#L124-L512 for example of all of |
The `rawMessage` provides the message with a guarantee not to include any colors.
7e5230d
to
4fbb209
Compare
Implementation lives here: https://github.com/facebook/jest/blob/1eb02fd41ad6840350a5b2c0636151e2da8bcd8b/packages/jest-jasmine2/src/assert_support.js |
I'm not convinced this change adds real value either.
So I'll -1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation seems 💯
Not convinced about value.
@refack please be aware that it is actually not a good idea to change the |
Agreed, but still a valid solution for root applications i.e. tools like |
Ping @refack |
IMHO So Lines 43 to 48 in acc328e
Should be: return util.inspect(
val,
{ compact: false, customInspect: false, colors: false }
).split('\n'); |
How about going with @refack’s suggestion, and then, for color support, add a custom inspect override for assertion errors that could provide the right colorization, if that subsequent |
@addaleax I am not sure I understand your implementation suggestion correct. Can you please elaborate? Besides that: I personally believe using colors is a good idea and we should in general try to use more colors in core. It improves the readability a lot out of my perspective. Right now the error message will only contain colors if the TTY supports colors and colors did not get deactivated by the user or the user (or a module) explicitly changed the util.inspect.defaultOptions to always use colors. |
@BridgeAR The idea is:
That way we don’t have to deal with color support checking while creating the error, where we can’t yet know how it’s going to end up being used. |
FWIW, the thing I want is no colors and no diff, and colors are easy to strip out (https://github.com/chalk/strip-ansi). But the diff forces us to manually split up |
That sounds like you want to know about the @addaleax thanks for explaining your idea in more detail. I am going to give this another thought but right now I still think it would be nicer to add colors as a default even if colors is not explicitly activated. |
We want So the |
Can you explain why you think that? |
@BridgeAR I played around with my suggestion but noticed that we don’t actually use I still think it would be nicer if we didn’t add color support based on feature detection for |
Most users rely on default values and those are often very old and not optimal. Some times that is for historical reasons but most often just because originally there was no better solution. Now that there is a rough color detection, we should start relying on that so we can provide colors when we determine that the user is capable of handling those. The user can still deactivate those in general. @refack please take another look. I would like to go ahead and land this if you do not feel strongly against it. |
@refack PTAL |
The changed error message (diff and the wording around the operator) is the only thing breaking Jest's test suite using 10-rc.1. It'd be great to land a solution for this one way or the other. The changed wording we can work around in our test, but the double diff looks weird, so that'll require a code change in Jest. To be clear, for consumers of Jest this is not really an issue (double diff won't break anybody, it just takes up more space in the terminal - although we'll want to remove it in the long run), it's just Jest's own assertions that the interop works which break. (This message looka kinda passive-aggresive even to my own eyes. That's not my intention at all ❤️). EDIT: Most of the discussion in this PR has been about the colors - those aren't really an issue for us (we can use strip-ansi). It's the diff that I want to avoid 🙂 |
@SimenB I am not sure what you mean with "double diff". I guess you mean Jest creates a diff and Node.js creates a diff as well? The I still recommend to just rely on the properties of the thrown error instead of relying on the message. That seems to be best for Jest. To be more independent in tests see e.g., https://github.com/eslint/eslint/pull/10182/files. |
Correct. See this screengrab using rc.1: The flipped around
Oh, I though
While setting up some code examples to show what I mean, I found the property
Let me make a quick test to see if we can just move to that, and I'll report back. EDIT: Yeah, that's enough for Jest. Just doing a So, at least for Jest's use case, this is not needed 🙂 |
That is a very valid point. I am going to check what is most commonly used pattern and improve that if it there is a "standard" to it that is actually flipped to the current implementation.
The docs landed recently as I pointed out above (#19723 (comment), #19723 (comment) & #19723 (comment)).
🎉 🎈
Yes, I guess then there is no real reason to actually land this. I am going to close the PR therefore. Something in general: Thanks a lot for the constructive feedback. There were some great findings and I am going to try to keep an closer eye on Jest. |
Thank you for the patience! For posterity, PR in Jest for node 10 support: jestjs/jest#6055 EDIT: Also working on getting Jest into CITGM, should highlight potential issues at least 🙂 nodejs/citgm#560 |
PR-URL: nodejs#24204 Fixes: nodejs#24193 Refs: nodejs#19723 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
PR-URL: nodejs#24204 Fixes: nodejs#24193 Refs: nodejs#19723 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The
rawMessage
provides the message with a guarantee not to include colors.This was requested recently by @SimenB. I personally am not a fan of this. But I thought this way we can have a proper discussion about adding this property or not.
If a user sets the
util.inspect
'colors' default options to true, assertion error messages are currently going to contain colors. The same applies to multiple errors coming from the assertstrict
mode.Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes