fix(expect-utils): honour SERIALIZABLE_PROPERTIES in equality checks - #16461

Summary

SERIALIZABLE_PROPERTIES currently only reaches one half of the story: jest-matcher-utils consults it when printing a diff, but the equality matchers ignore it, so an object that declares which of its properties are serializable still fails toEqual on the properties it told Jest not to care about:

const {SERIALIZABLE_PROPERTIES} = require('jest-matcher-utils');

class Volume {
  constructor(amount, unit, label) {
    this.amount = amount;
    this.unit = unit;
    this.label = label;
  }
}

Volume.prototype[SERIALIZABLE_PROPERTIES] = ['amount', 'unit'];

test('only compares the serializable properties', () => {
  // prints a diff mentioning only `amount`/`unit`…
  expect(new Volume(1, 'L', 'first')).toEqual(new Volume(2, 'L', 'second'));
});

On main the diff printer filters label out while eq() still walks it, so the matcher reports a difference on a property it deliberately hides from the printed diff. This aligns the two, as discussed in the issue:

• @SimenB: "I think it makes sense to align, but I'll defer to @georgekaran"
• @georgekaran (who added the feature): "Personally the second option [apply the properties to the equality checkers] makes more sense to me"

What the change does

eq()'s keys() helper now skips own enumerable string and symbol keys that the object declared as not serializable, mirroring getSerializableProperties() from jest-matcher-utils/src/deepCyclicCopyReplaceable.ts (looked up via Symbol.for('@jest/serializableProperties'), so @jest/expect-utils keeps no dependency on jest-matcher-utils). The declaration is inherited, so setting it on a class prototype covers every instance, exactly like the printing path.

The behaviour stays opt-in: an object that declares nothing is compared exactly as before.

@Fryuni's objection

In the issue, @Fryuni argued that equality is about runtime values rather than serialized representations, with Array(2) vs [undefined, undefined] as the counterexample. That concern is the reason for the explicit exclusion list in isBuiltInObject(): arrays, typed arrays, ArrayBuffer, Date, Error, Map, Promise, RegExp, Set and WeakMap/WeakSet never consult the declaration, because they already have their own comparison semantics (iterableEquality, item-wise comparison, message, and so on). The sparse-array example therefore behaves exactly as it does on main, and so do asymmetric matchers. A user has to opt in on a class of their own.

One visible consequence, which follows directly from aligning with the printer and is documented in docs/ExpectAPI.md: for an instance that declares a subset, toEqual(instance, plainObjectWithTheSameKeys) is now true while toStrictEqual stays false, since the latter still compares prototypes.

Fixes #15073

Tests

packages/expect-utils/src/__tests__/jasmineUtils.test.ts covers string keys, symbol keys, nested objects/arrays/Maps, inherited declarations, empty declarations, a throwing getter and the excluded built-ins, plus no-regression cases (a class that declares nothing, an object that declares undefined, built-ins that carry the symbol).

packages/expect/src/__tests__/serializableProperties.test.ts covers toEqual, toStrictEqual, toHaveBeenCalledWith and the asymmetric matcher path end to end.

Locally (with the new tests in place and packages/expect-utils packages/expect packages/jest-matcher-utils packages/jest-snapshot packages/jest-circus):

• main: 51 suites, 1519 passed, 0 failed
• this branch: 53 suites, 1532 passed, 0 failed — i.e. +2 suites / +13 tests, no regressions

yarn build:ts, yarn typecheck:tests, yarn eslint and yarn prettier --check are clean.