[Bug]: jest `expect.extend` is failing when upgrading to `v27.5.1`

Version

27.5.1

Steps to reproduce

repo: https://github.com/rmirro/jest-expect-extend

1. npm i
2. npm test

Expected behavior

All four tests should pass.

Actual behavior

The forth test (handles undefined as 2nd argument via expect) is not passing after upgrading to jest v27.5.1.

I left console.log output below to illustrate that both tests that utilize expect.optionalFn() are considered passing:

$ npm test

> jest-expect-extend@1.0.0 test /Users/robertmirro/blah/jest-expect-extend
> jest

  console.log
    optionalFn: fn:function pass:true

      at Object.optionalFn (expect-extend.test.js:7:13)

  console.log
    optionalFn: fn:undefined pass:true

      at Object.optionalFn (expect-extend.test.js:7:13)

 FAIL  ./expect-extend.test.js
  expect.extend
    ✓ handles fn as 2nd argument (3 ms)
    ✓ handles undefined as 2nd argument (1 ms)
    ✓ handles fn as 2nd argument via expect (19 ms)
    ✕ handles undefined as 2nd argument via expect (4 ms)

  ● expect.extend › handles undefined as 2nd argument via expect

    expect(jest.fn()).toHaveBeenCalledWith(...expected)

    - Expected
    + Received

      {"id": 1, "name": "name"},
      undefined,

    Number of calls: 1

      54 |   test('handles undefined as 2nd argument via expect', () => {
      55 |     testFn(argObj, undefined);
    > 56 |     expect(testFn).toHaveBeenCalledWith(
         |                    ^
      57 |       argObj,
      58 |       expect.optionalFn()
      59 |     );

      at Object.<anonymous> (expect-extend.test.js:56:20)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 3 passed, 4 total
Snapshots:   0 total
Time:        0.511 s, estimated 1 s
Ran all test suites.
npm ERR! Test failed.  See above for more details.

Additional context

It appears that expect.extend is not handling undefined now:

expect.extend({
  optionalFn(fn) {
    const pass = fn === undefined || typeof fn === 'function';
    console.log(`optionalFn: fn:${typeof fn} pass:${pass}`);

    return {
      pass,
      message: () =>
        'fn argument must either be a function or undefined.',
    };
  },
});

test('handles undefined as 2nd argument via expect', () => {
  testFn(argObj, undefined);
  expect(testFn).toHaveBeenCalledWith(
    argObj,
    expect.optionalFn()
  );
});

All of these tests are passing with jest v26.6.3 (the version we were using prior to upgrading to v27.5.1):

$ npm test

> jest-expect-extend@1.0.0 test /Users/robertmirro/blah/jest-expect-extend
> jest

 PASS  ./expect-extend.test.js
  expect.extend
    ✓ handles fn as 2nd argument (3 ms)
    ✓ handles undefined as 2nd argument
    ✓ handles fn as 2nd argument via expect (15 ms)
    ✓ handles undefined as 2nd argument via expect (1 ms)

  console.log
    optionalFn: fn:function pass:true

      at optionalFn (expect-extend.test.js:7:13)

  console.log
    optionalFn: fn:undefined pass:true

      at optionalFn (expect-extend.test.js:7:13)

Test Suites: 1 passed, 1 total
Tests:       4 passed, 4 total
Snapshots:   0 total
Time:        2.859 s
Ran all test suites.

$ npx envinfo --preset jest
npx: installed 1 in 1.568s

  System:
    OS: macOS 11.6
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 14.16.0 - ~/.nvm/versions/node/v14.16.0/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.11 - ~/.nvm/versions/node/v14.16.0/bin/npm
  npmPackages:
    jest: ^26.6.3 => 26.6.3 

Environment

$ npx envinfo --preset jest
npx: installed 1 in 1.725s

  System:
    OS: macOS 11.6
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 14.16.0 - ~/.nvm/versions/node/v14.16.0/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.11 - ~/.nvm/versions/node/v14.16.0/bin/npm
  npmPackages:
    jest: ^27.5.1 => 27.5.1 

[SimenB]

git bisect says this changed in #11061.

/cc @dubzzz

[dubzzz]

That said, I’d consider it a bug that an asymmetric matcher that returns {pass: true} can still cause failure, for both arrays and objects

Maybe we could do something to patch this behaviour for matchers 🤔 I have not found anything obvious yet but we could definitely try something to fix the matcher case for both calls to functions and isEqual (which obviously is not ideal today - and was not - with such matcher)