Skip to content

[Feature]: remove alised matchersΒ #13164

@G-Rath

Description

@G-Rath

πŸš€ Feature Proposal

From jest-community/eslint-plugin-jest#1210 (comment)

Let's axe the following matchers:

expect(a).toBeCalled();
expect(a).toBeCalledTimes();
expect(a).toBeCalledWith();
expect(a).lastCalledWith();
expect(a).nthCalledWith();
expect(a).toReturn();
expect(a).toReturnTimes();
expect(a).toReturnWith();
expect(a).lastReturnedWith();
expect(a).nthReturnedWith();
expect(a).toThrowError();

in favor of their native counterparts:

expect(a).toHaveBeenCalled();
expect(a).toHaveBeenCalledTimes();
expect(a).toHaveBeenCalledWith();
expect(a).toHaveBeenLastCalledWith();
expect(a).toHaveBeenNthCalledWith();
expect(a).toHaveReturned();
expect(a).toHaveReturnedTimes();
expect(a).toHaveReturnedWith();
expect(a).toHaveLastReturnedWith();
expect(a).toHaveNthReturnedWith();
expect(a).toThrow();

Motivation

  • Removing duplicated matchers will return Jest's size a little
  • We've already identified the preferred matcher in each set
  • no-alias-methods provides a migration method, which can be automatically fixed
  • it's easy to extend the matchers Jest has, so folks can re-alias these themselves if they wish
  • eventually this would let external tools (like eslint-plugin-jest) shave off a little complexity i.e. by not having to check for two matchers

Example

No response

Pitch

Because the matchers are in the jest core.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions