@sunesimonsen @alexjeffburke, any objections to landing this in a minor given that it doesn't break anything, including the 🐦 build?

@papandreou would you be able to drop a refresher on what the effect of this is? I vaguely remember the change but have no memory of what it achieves lol.

The effect is that the expect that we hand into assertions will now have the "top level" expect in its prototype chain, so it's effectively a subclass of it. Before it was detached from it, but was still calling into it in a bunch of ways. If we make this change, it'll allow us to share more functionality between the two by just calling through to the method/property in the top level expect without installing a specific method on the child that closes over the top level expect.

This seems like a sane direction to go in no matter what, but IIRC the specific occasion was that it would be easier to make the expect.it camel case equivalent work on child expects if that's the case, eg.

expect.addAssertion('<object> to have foo property that bars', (expect, subject, value) => {
  expect(object, 'to satisfy', {
    foo: expect.toBar()
  });
});

... where the alternative would be to attach every expanded camelCase assertion to child expects also, which would be expensive.

@alexjeffburke, did that make sense? :)