Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeScript declarations are not working when used with @jest/globals #674

Open
slavafomin opened this issue Jan 16, 2024 · 1 comment
Open

Comments

@slavafomin
Copy link

slavafomin commented Jan 16, 2024

Hello!

Thank you for this great library!

However, when using TypeScript and Jest with @jest/globals, the declarations provided by the package doesn't work. E.g.:

import 'jest-extended';

import { expect } from '@jest/globals';

// TS2339: Property toIncludeSameMembers does not exist on type
expect([]).toIncludeSameMembers([]);

Have you considered this use case? Thank you.

@int19h
Copy link

int19h commented Aug 7, 2024

To make the asymmetric matchers visible, you can do the following in your globals.d.ts or equivalent:

import * as jestExtended from 'jest-extended';
type JestExtended = typeof jestExtended;
declare module 'expect' {
    interface AsymmetricMatchers extends JestExtended {}
}

However, this requires you to use asymmetric matching in all cases by using toEqual; e.g. for your original example:

expect([]).toEqual(expect.toIncludeSameMembers([]));

For regular matchers you can also kinda sorta do this:

declare module 'expect' {
    interface Matchers extends JestExtended {}
}

However the problem is that the object exported by jest-extended is of type CustomMatchers<any>, which results in expect() returning an object that allows arbitrary members, compromising type safety. If the package exported the generic CustomMatchers interface itself, alleviating the need for typeof, we could do:

import {CustomMatchers} from 'jest-extended';
declare module 'expect' {
    interface Matchers<R> extends CustomMatchers<R> {}
}

Of course, ideally, the package should just do this itself for both kinds of matchers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants