Repository navigation
Add partialDeepEqual() in strict assertion mode #62327
Description
Activity
- addedfeature requestIssues requesting new Node.js features.Issues requesting new Node.js features.
on Mar 18, 2026 - added a commit that references this issue
on Mar 18, 2026 I see three possibilities:
- Have only
partialDeepStrictEqual()(current version)- Advantage: We know that
partialDeepStrictEqual()does not exist in legacy mode. - Disadvantage: In strict mode, all methods have aliases without
strictexceptpartialDeepStrictEqual().
- Advantage: We know that
- Have
partialDeepStrictEqual()andpartialDeepEqual()(the worst-case scenario 👎)- Advantage: All methods exist in both modes, and they are all aliases without strict in strict mode.
- Disadvantage: You have to add a deprecated method.
- Have
partialDeepStrictEqual()and its aliaspartialDeepEqual()only in strict mode (my suggestion ❤️)- Advantage: All methods have their aliases without
strictin strict mode. - Disadvantage:
partialDeepEqual()only exists in strict mode.
- Advantage: All methods have their aliases without
In my projects, I only use strict mode and aliases without
strict. Aliases allow for shorter method names and make the code more readable. I'd really like to have thepartialDeepEqual()alias (only in strict mode) for these two reasons, as well as to maintain consistency in my asserts.- Have only
The shape of the
assertandassert/strictmodules should remain equivalent. We shouldn't start adding pseudo-aliases to one that don't exist in the other, particularly when the only real argument is "it looks nicer".Reacted by Jordan HarbandHaving
strictin any of our names is not ideal and it is purely a legacy issue that we can not really solve.The strict mode was implemented with avoiding that word while still having the overall implementation as expected. I slightly lean on the third suggestion therefore (adding the alias in strict mode only), while I also very well understand the reasoning of @Renegade334 to not introduce a pseudo-alias. This is a tricky not perfect API world and either way it is not ideal.
Reacted by Sébastien RègneI’d prefer 2; i weigh consistency more highly than “non-strict methods are icky”
github-actions commented
on Jul 20, 2026 on Jul 20, 2026 – with GitHub ActionsContributorMore actionsThis issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jul 20, 2026 - addednever-staleIssues and PRs exempt from automated stale handling.Issues and PRs exempt from automated stale handling.and removedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Jul 24, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsAwaiting Triage
What is the problem this feature will solve?
I use strict assertion mode in my tests:
But the
partialDeepEqual()doesn't exist. You have to usepartialDeepStrictEqual()that has the word Strict in its name, whereas the other methods do not.What is the feature you are proposing to solve the problem?
The
"node:assert/strict"module should re-exportpartialDeepStrictEqual()with the namepartialDeepEqual()so that function names are consistent in strict assertion mode.Additional information
The
partialDeepStrictEqual()function was added with #54630. I couldn't find any references to the terms strict assertion mode."Re-export" takes place in two locations:
Probably for
import assert from "node:assert/strict"node/lib/assert.js
Lines 126 to 131 in 56aba88
Probably for
import { strict as assert } from "node:assert"node/lib/assert.js
Lines 894 to 899 in 56aba88
I don't think adding the following two lines is enough?
Because
partialDeepEqual()doesn't exist in legacy assertion mode. So we need to manage the fact that theAsserttype will be different between the two modes.