`valid-expect` should allow Vitest's `not.resolves` and `not.rejects` chains

[nami8824]

Summary

valid-expect currently treats some expect modifier combinations in a Jest-like way.

However, Vitest's expect API is Chai-style chainable, so not.resolves and not.rejects are valid Vitest assertions:

await expect(Promise.resolve(1)).not.resolves.toBe(2)
await expect(Promise.reject(new Error('error'))).not.rejects.toThrow('other')

These chains should not be reported as modifierUnknown.

This is different from Jest. In Jest, promise modifiers are exposed as resolves.not / rejects.not, and not.resolves / not.rejects are not part of the runtime API.

For example, this fails in Jest:

await expect(Promise.resolve(1)).not.resolves.toBe(2)

with:

TypeError: Cannot read properties of undefined (reading 'toBe')

The same assertion passes in Vitest.

Reproduction

This should be valid:

await expect(Promise.resolve(1)).not.resolves.toBe(2)

This should be reported as missing await / return:

expect(Promise.resolve(1)).not.resolves.toBe(2)

Currently, the unawaited case can be reported as modifierUnknown instead of being treated as a valid async assertion chain.

Expected behavior

valid-expect should treat not.resolves and not.rejects as valid Vitest expect chains.

They should still be treated as async assertions because resolves / rejects is present.

Notes

This should intentionally differ from eslint-plugin-jest, because Jest and Vitest expose different expect chain APIs.

This issue does not cover duplicate not chains such as not.not, since that is more about lint policy than promise modifier compatibility.