Probably this is because toMatchObject is checking hasOwnProperty

It looks like proxy can intercept more things. For example, something like this can make "more equivalent" object as plain one and toMatchObject and error diff work https://stackblitz.com/edit/vitest-dev-vitest-kuacmv?file=test%2Frepro.test.ts

const proxyObj = new Proxy(
  {},
  {
    get(target, prop, receiver) {
      if (prop === 'bar') {
        return 'foo';
      }
    },
    getOwnPropertyDescriptor(target, prop) {
      if (prop === 'bar') {
        return { configurable: true, enumerable: true };
      }
      return Reflect.getOwnPropertyDescriptor(target, prop);
    },
    ownKeys() {
      return ['bar'];
    },
  }
);

// pass
expect(proxyObj).toMatchObject({ bar: 'foo' })

// error diff
//   Object {
// -   "bar": "not-foo",
// +   "bar": "foo",
//   }
expect(proxyObj).toMatchObject({ bar: 'not-foo' })

Though this seems technically possible, I don' think people usually go this far for proxy implementation, so it might make sense to loosen toMatchObject (or specifically subsetEquality) to skip hasOwnProperty check. It looks mostly harmless removing this line though I haven't tested.

expect.objectContaining({ bar: "foo" }) also requires hasOwnProperty. So, if we change toMatchObject, then we probably should change this too.
https://stackblitz.com/edit/vitest-dev-vitest-dr5jfq?file=test%2Frepro.test.ts

@jimmycallin Btw, can you explain your actual use case? We think either behavior seems fine (current one or #6675), but knowing a concrete use case would help decisions. For example, is proxy coming from some well-known library or your specific implementation?

@jimmycallin Btw, can you explain your actual use case? We think either behavior seems fine (current one or #6675), but knowing a concrete use case would help decisions. For example, is proxy coming from some well-known library or your specific implementation?

Sure! It may be a bit esoteric, but we are using react-query which has a concept of tracked queries, which checks which properties you actually use to reduce rerenders in react. We have a wrapper around a useQuery function that adds a few properties, which naively would look something like this:

function useWrapper() {
    const query = useQuery(...);
    return {...query, additionalProperty: true }
}

Unfortunately the rest spread causes it to "trigger" each property, which nullifies the optimization. So we use a proxy to get around it:

function useWrapper() {
  const query = useQuery({...});
  return new Proxy(query, {
    get(target, prop, receiver) {
      if (prop === "additionalProp") {
        return true;
      }
      return Reflect.get(target, prop, receiver);
    },
  });
}

Then we use react-testing-library to test the result of the hook.

Hope this makes sense!

Interesting, wrapping useQuery sounds like a sensible use case.
How about defining getOwnPropertyDescriptor / ownKeys? I guess it would be too tedious? (honestly I didn't even know such proxy handler exists 😄)

Interesting, wrapping useQuery sounds like a sensible use case. How about defining getOwnPropertyDescriptor / ownKeys? I guess it would be too tedious? (honestly I didn't even know such proxy handler exists 😄)

We had that previously, but just changed to Proxy after I saw this discussion that Proxy is a lot more performant: TanStack/query#8091

Which is what triggered this issue. :)

What I was suggesting is to implement getOwnPropertyDescriptor and ownKeys of proxy:

function useWrapper() {
  const query = useQuery({...});
  return new Proxy(query, {
    get(target, prop, receiver) {
      if (prop === "additionalProp") {
        return true;
      }
      return Reflect.get(target, prop, receiver);
    },
    getOwnPropertyDescriptor(target, prop) {
      if (prop === 'additionalProp') {
        return { configurable: true, enumerable: true };
      }
      return Reflect.getOwnPropertyDescriptor(target, prop);
    },
    ownKeys(target) {
      return [...Reflect.ownKeys(target, prop), 'additionalProp']
    },
  });
}

But, I think TanStack/query#8092 proves the point. If useQuery implements only Proxy.get, then Reflect.getOwnPropertyDescriptor won't probably work for downstream proxy.

EDIT: Oh wait, maybe their useQuery is fine because they have new Proxy(result, { get }), so default getOwnPropertyDescriptor/ownKeys can enumerate the ones from result.

After discussing with the team, we decided to not remove hasOwnProperty check on our side.
Since proxy can be implemented properly to imitate an object, it's not good for test framework to go loose about this.

Here is an alternative if users need to implement proxy for Vitest assertions to work.

const obj = { foo: "bar", bar: "foo" };

const proxyBad = new Proxy(
  { foo: "bar" },
  {
    get(target, prop, receiver) {
      if (prop === "bar") {
        return "foo";
      }
    },
  },
);

const proxyGood1 = new Proxy(
  // 👇 define key on base object
  { foo: "bar", bar: undefined }, 
  {
    get(target, prop, receiver) {
      if (prop === "bar") {
        return "foo";
      }
    },
  },
);

const proxyGood2 = new Proxy(
  { foo: "bar" },
  {
    get(target, prop, receiver) {
      if (prop === "bar") {
        return "foo";
      }
      return Reflect.get(target, prop, receiver)
    },
    // 👇 define custom handler
    getOwnPropertyDescriptor(target, prop) {
      if (prop === 'bar') {
        return { configurable: true, enumerable: true };
      }
      return Reflect.getOwnPropertyDescriptor(target, prop);
    }
  },
);

Object.hasOwn(obj, 'bar') // true
Object.hasOwn(proxyBad, 'bar') // false
Object.hasOwn(proxyGood1, 'bar') // true
Object.hasOwn(proxyGood2, 'bar') // true