toContainEqual, toHaveProperty, toBeOneOf and return matchers treat any two Maps or Sets as equal

Describe the bug

Nine matchers that take a value to compare against compare Maps and Sets without iterableEquality, so any two of them match. All of these pass on 5.0.1:

const a = new Map([['a', 1]])
const b = new Map([['b', 2]])

expect([a]).toContainEqual(b)
expect([new Set([1])]).toContainEqual(new Set([2]))
expect({ m: a }).toHaveProperty('m', b)
expect(a).toBeOneOf([b])

const fn = vi.fn(() => a); fn()
expect(fn).toHaveReturnedWith(b)
expect(fn).toHaveLastReturnedWith(b)
expect(fn).toHaveNthReturnedWith(1, b)
// and the three *ResolvedWith variants

Controls fail correctly: expect(a).toEqual(b) and expect(fn).toHaveBeenCalledWith(b) both reject.

The six return/resolve matchers also drop customTesters, so a tester registered with expect.addEqualityTesters applies to toHaveBeenCalledWith but not to toHaveReturnedWith.

Cause

packages/expect/src/jest-expect.ts: toContainEqual and toHaveProperty call jestEquals(..., customTesters) without appending iterableEquality, unlike toEqual, toHaveBeenCalledWith and every other matcher in the file. The six return/resolve matchers call bare jestEquals(a, b) with no testers at all. toBeOneOf in custom-matchers.ts has the same gap.

Without iterableEquality, equals() falls through to own-enumerable-property comparison, and a Map or Set has none, so they compare equal.

Reproduction

The snippet above in any project with vitest@5.0.1. Every expect(...) line passes; each should fail.

System Info

vitest 5.0.1
node 22.18.0
win32 x64

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines
• Read the docs
• Check that there isn't already an issue that reports the same bug
• Check that this is a concrete bug
• The provided reproduction is a minimal reproducible example of the bug

I have a fix with tests on a branch. I'll open the PR once #11295 is resolved, since outside contributors get one open PR at a time. Claude helped me find and verify this.

Start in packages/expect/src/jest-expect.ts and custom-matchers.ts, where the affected equality calls are identified. Reproduce the Map and Set cases from the issue, then inspect the existing matcher tests and verify that all listed matchers reject unequal values and honor custom testers; the issue notes that a fix with tests already exists on a branch.