Skip to content

Add partialDeepEqual() in strict assertion mode #62327

Description

@regseb

What is the problem this feature will solve?

I use strict assertion mode in my tests:

import assert from "node:assert/strict";

assert.equal("...", "...");
assert.deepEqual({ "..." }, { "..." });
assert.partialDeepEqual({ "..." }, { "..." });

But the partialDeepEqual() doesn't exist. You have to use partialDeepStrictEqual() 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-export partialDeepStrictEqual() with the name partialDeepEqual() 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

    if (options.strict) {
    this.equal = this.strictEqual;
    this.deepEqual = this.deepStrictEqual;
    this.notEqual = this.notStrictEqual;
    this.notDeepEqual = this.notDeepStrictEqual;
    }

  • Probably for import { strict as assert } from "node:assert"

    node/lib/assert.js

    Lines 894 to 899 in 56aba88

    assert.strict = ObjectAssign(strict, assert, {
    equal: assert.strictEqual,
    deepEqual: assert.deepStrictEqual,
    notEqual: assert.notStrictEqual,
    notDeepEqual: assert.notDeepStrictEqual,
    });

I don't think adding the following two lines is enough?

// if (options.strict) { 
this.partialDeepEqual = this.partialDeepStrictEqual; 

// assert.strict = ObjectAssign(strict, assert, { 
partialDeepEqual: assert.partialDeepStrictEqual, 

Because partialDeepEqual() doesn't exist in legacy assertion mode. So we need to manage the fact that the Assert type will be different between the two modes.

Activity

  1. regseb commented on Mar 25, 2026

    @regseb
    ContributorAuthor

    I see three possibilities:

    1. 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 strict except partialDeepStrictEqual().
    2. Have partialDeepStrictEqual() and partialDeepEqual() (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.
    3. Have partialDeepStrictEqual() and its alias partialDeepEqual() only in strict mode (my suggestion ❤️)
      • Advantage: All methods have their aliases without strict in strict mode.
      • Disadvantage: partialDeepEqual() only exists in strict mode.

    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 the partialDeepEqual() alias (only in strict mode) for these two reasons, as well as to maintain consistency in my asserts.

  2. Renegade334 commented on Mar 27, 2026

    @Renegade334
    Member

    The shape of the assert and assert/strict modules 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".

  3. BridgeAR commented on Mar 30, 2026

    @BridgeAR
    Member

    Having strict in 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.

  4. ljharb commented on Mar 30, 2026

    @ljharb
    SponsorMember

    I’d prefer 2; i weigh consistency more highly than “non-strict methods are icky”

  5. github-actions commented on Jul 20, 2026

    @github-actions
    Contributor

    This 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.

  6. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Jul 20, 2026
  7. added
    never-staleIssues and PRs exempt from automated stale handling.
    and removed
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Jul 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestIssues requesting new Node.js features.never-staleIssues and PRs exempt from automated stale handling.

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions