-
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
tools,test: enforce deepStrictEqual over deepEqual #6213
Conversation
Buffer.from(expected)); | ||
assert.deepEqual(Buffer.from('__--_--_--__', 'base64'), | ||
assert.deepStrictEqual(Buffer.from('__--_--_--__', 'base64'), | ||
Buffer.from(expected)); |
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.
Can you line up the arguments here?
Should we also make assert only importable as Also, is it possible for the rule to check Sidenote: while |
I can foresee cases where enforcing this rule strictly could cause issues but turning the rule off for individual tests that require lenient handling makes sense... so +1. Haven't reviewed the changes so not giving a LGTM yet. |
b54ca5d
to
b0aaef6
Compare
Fixed all of @bnoordhuis's nits, rebased, force pushed. |
LGTM |
1 similar comment
LGTM |
@bnoordhuis ... can you take another look? |
@jasnell: Rebased and force pushed. |
@Fishrock123 asked:
It's a good question and something I thought about when I wrote the rule. The answer is yes, but I'd be -0.5 on something like that. There are basically two reasons. First, it won't stop people from re-assigning:
So we're going to have an imperfect rule still. And if we're going to have an imperfect rule, I'd rather have it be simple and imperfect than convoluted and imperfect. Second, you either have to enforce the identifier name in this rule or you have to create a separate rule to enforce it. If you put it in this rule, it's a bit of scope creep that doesn't quite pass the smell test. This rule is about avoiding Anyway, that was my thinking for not doing that. I'm not 100% opposed, but I am predisposed to be skeptical of going that route. Sorry for the longwinded response to a simple question. |
@Fishrock123 asked:
Yes. There aren't any instances of that in the current code base. Future enhancement after this bakes in on master for a while (and if it can be done without adding too much complexity to the rule)? Or maybe something to discuss in another thread along with other non-strict assert functions we may want to avoid? |
Another CI, since I rebased and force pushed: https://ci.nodejs.org/job/node-test-pull-request/2310/ EDIT: Well, that certainly didn't go well... EDIT 2: I'm guessing e38bade is the source of the trouble. We have to modify the tests so that the expected value does not inherit from EDIT 3: dba245f too. |
OK, all fixed up. These changes uncovered a bug (or at least I consider it a bug) that is now fixed (or reduced, in any event, if it isn't fixed in all scenarios) in the first commit. If you looked at it before, it would be great if you could look again because there are some significant changes. @cjihrig @jasnell @bnoordhuis @mscdex @Fishrock123 @nodejs/testing |
@Trott ... that fix works for me. |
CI is good except for one buildbot failure. |
@Trott... Looks like this needs a quick rebase before landing. |
In preparation for a lint rule that will enforce assert.deepStrictEqual() over assert.deepEqual(), change tests and benchmarks accordingly. For tests and benchmarks that are testing or benchmarking assert.deepEqual() itself, apply a comment to ignore the upcoming rule.
Introduce a lint rule that enforces use of `assert.deepStrictEqual()` over `assert.deepEqual()`.
@jasnell Rebased and force-pushed. Added labels to not land on v4 or v5 because some changes depend on previous semver major changes. New CI: https://ci.nodejs.org/job/node-test-pull-request/2347/ |
Only failure in Ci is a known flaky test. |
LGTM |
Last (or hopefully last) call for additional reviews or objections. If no objections, I'll land this at or soon after 9PM UTC (that's 2PM PDT) tomorrow (Friday). |
Whoops, meant to do a /cc @nodejs/collaborators on that last comment. Which, for the benefit of those only getting this via email notification, was:
|
In preparation for a lint rule that will enforce assert.deepStrictEqual() over assert.deepEqual(), change tests and benchmarks accordingly. For tests and benchmarks that are testing or benchmarking assert.deepEqual() itself, apply a comment to ignore the upcoming rule. PR-URL: nodejs#6213 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
Introduce a lint rule that enforces use of `assert.deepStrictEqual()` over `assert.deepEqual()`. PR-URL: nodejs#6213 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
In preparation for a lint rule that will enforce assert.deepStrictEqual() over assert.deepEqual(), change tests and benchmarks accordingly. For tests and benchmarks that are testing or benchmarking assert.deepEqual() itself, apply a comment to ignore the upcoming rule. PR-URL: nodejs#6213 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
Introduce a lint rule that enforces use of `assert.deepStrictEqual()` over `assert.deepEqual()`. PR-URL: nodejs#6213 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
In preparation for a lint rule that will enforce assert.deepStrictEqual() over assert.deepEqual(), change tests and benchmarks accordingly. For tests and benchmarks that are testing or benchmarking assert.deepEqual() itself, apply a comment to ignore the upcoming rule. PR-URL: #6213 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
Introduce a lint rule that enforces use of `assert.deepStrictEqual()` over `assert.deepEqual()`. PR-URL: #6213 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
Checklist
Affected core subsystem(s)
tools, test, benchmark
Description of change
Introduce a lint rule that enforces use of
assert.deepStrictEqual()
over
assert.deepEqual()
.This is a proof of concept inspired by @Fishrock123 wondering in #6196 (comment):
I like it, but (like Fishrock123) I don't know if others will feel the same.
If this is deemed a good idea, it can optionally evolve from
no-deepEqual
to something that flags all non-strict assertions, perhaps only in the tests. Not going to bother, though, if there isn't consensus on this.