-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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: improve the strict equal messages #23056
Conversation
In case reference (un)equal objects fail in assertion, it should be clear that it is about the reference equality and not about the object properties. This is fixed by improving the message in such cases. Refs: nodejs#22763
lib/internal/assert.js
Outdated
@@ -13,10 +13,13 @@ let white = ''; | |||
const kReadableOperator = { | |||
deepStrictEqual: 'Expected inputs to be strictly deep-equal:', | |||
strictEqual: 'Expected inputs to be strictly equal:', | |||
strictEqualObject: 'Expected reference equal inputs but got:', |
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.
One small suggestion here, can't we have:
Expected "actual" reference to be equal to "expected" but got:
. For me the word inputs
(why we use plural word here?) is bit confusing and also the counter part message (notStrictEqualObject
) uses the term "actual" and "expected", so it would make sense to use the same here too.
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.
You are right that either notStrictEqualObject
should be 'Expected inputs not to be reference equal:'
or that this message should be changed.
I used inputs
instead of naming the variables because the message itself is significantly shorter that way. But I personally have no strong opinion on it. Maybe others can weight in? :)
@Trott @vsemozhetbyt it would be good if you could also have a look :)
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.
If the current wording remains, maybe this should be reference-equal
since it’s used as a single adjective? I’ve also always been wondering about inputs
in these error messages … it makes sense from the PoV of the assert
module, but for me something more generic like values
would seem more intuitive?
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.
No strong opinion)
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.
No strong opinion from me either. Maybe @nodejs/documentation even though this isn't a doc question?
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 decided to go for a more verbose version and I also added the dash in reference-equal
.
I also added another commit to switch from inputs
to values
.
The wording seems clearer when using `values` instead of `inputs`.
d7c33aa
to
8532f22
Compare
Resumed build: https://ci.nodejs.org/job/node-test-pull-request/17430/ ✔️ (besides Windows) @nodejs/util PTAL |
Windows rebuild: https://ci.nodejs.org/job/node-test-commit-windows-fanned/21037/ |
I think this is semver-major, as the change to those message could lead to test breakage in the ecosystem. |
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.
LGTM
@mcollina any change to the message could theoretically break the ecosystem but we did not handle it that way in almost all cases. This was an issue in a few cases before but all known ones were already fixed not to rely on the message in that way anymore. So if at all, it would already be broken and should not break any more. That's why I do not think that it's semver-major. |
@nodejs/tsc PTAL |
Ok |
Can you please confirm with a CITGM run? |
CITGM (this PR) https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1561/ (when looking at the current citgm failures it seems like we introduced something bad recently since the failures were normally significantly lower) Update: I did not find anything but it is difficult to look through everything due to the many failures in general at the moment. |
The wording changes look good to me. |
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.
LGTM.
Rebuild Windows again: https://ci.nodejs.org/job/node-test-commit-windows-fanned/21043/ |
Rebuild Windows again: https://ci.nodejs.org/job/node-test-commit-windows-fanned/21052/ ✔️ |
In case reference (un)equal objects fail in assertion, it should be clear that it is about the reference equality and not about the object properties. This is fixed by improving the message in such cases. Refs: nodejs#22763 PR-URL: nodejs#23056 Refs: nodejs#22763 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
The wording seems clearer when using `values` instead of `inputs`. PR-URL: nodejs#23056 Refs: nodejs#22763 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Ujjwal Sharma <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
@BridgeAR, is this still something that should be backported to v10.x? |
In case reference (un)equal objects fail in assertion, it should be
clear that it is about the reference equality and not about the
object properties. This is fixed by improving the message in such
cases.
Refs: #22763
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes