assert: fix TypeError on deepStrictEqual with null Map key or Set member

[semx]

assert.deepStrictEqual() (and util.isDeepStrictEqual()) throw a TypeError instead of comparing when the first Map has a null (or other primitive) key that lines up against object-only keys in the other map:

constassert=require('node:assert');consta=newMap([[null,1],[{},2]]);constb=newMap([[{},9],[{},9]]);assert.deepStrictEqual(a,b);// TypeError: Cannot read properties of null (reading 'constructor')// expected: an AssertionError (the maps are not deeply equal)

The same happens for an undefined key. Set has the identical problem for a null/undefined member (once the set is large enough to skip the small-set fast path):

assert.deepStrictEqual(newSet([null,{},{}]),newSet([{},{},{}]));// TypeError: Cannot read properties of null (reading 'constructor')

It only triggers in strict mode when the other collection's keys/members are all objects and their count equals the first collection's size.

Cause

In mapObjectEquiv and setObjectEquiv (lib/internal/util/comparisons.js), primitive/null keys and members are resolved directly via b.has() / b.get(), but that handling was gated behind extraChecks (array.length !== a.size). When the counts match, the gate is skipped and the primitive/null key/member falls through to objectComparisonStart, which dereferences .constructor and throws on null/undefined.

Fix

Handle primitive/null keys and members unconditionally — they can only match by identity and can never match through the object comparator — so they are always resolved by direct lookup and never reach objectComparisonStart. The collections above now compare as unequal (throwing an AssertionError, as expected) instead of throwing a TypeError. Object comparison is unchanged.

Added regression cases (null and undefined keys/members, for both Map and Set) to test/parallel/test-assert-deep.js.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.24%. Comparing base (8a3b11c) to head (19f16d9).
⚠️ Report is 41 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #64449 +/- ##
==========================================
- Coverage 90.24% 90.24% -0.01% 
==========================================
Files 741 741 Lines 241384 241429 +45 Branches 45480 45488 +8 ==========================================
+ Hits 217844 217875 +31 + Misses 15097 15090 -7 - Partials 8443 8464 +21 

Files with missing lines	Coverage Δ
lib/internal/util/comparisons.js	99.71% <100.00%> (+<0.01%)	⬆️

... and 38 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[semx]

This has two approvals (thanks @ljharb, @jasnell) and is still labelled needs-ci. Could a collaborator kick off a CI run?

Happy to rebase first if that helps — the branch is otherwise unchanged since the reviews.

[semx]

Following up: this has two approvals (thanks @ljharb, @jasnell) and is only waiting on CI to run so it can land. Could a collaborator start CI / apply the label so it can move through the commit-queue? Happy to rebase if needed. Thanks!

[ljharb]

First I think it needs a rebase?

[semx]

Rebased onto current main and force-pushed. There was one conflict, in lib/internal/util/comparisons.js: main has since landed an equivalent fix for the Map path (mapObjectEquiv), so I dropped that now-redundant hunk and kept the still-needed Set-path fix (setObjectEquiv) plus all four null/undefined regression tests. The final diff is just the Set fix + tests; the branch is one commit on top of main and both files pass node --check. Should be good for CI now — thanks!