Vitest typings override instead of augmenting module about jest-extended HOT 26 CLOSED

I think the preferable alternative here is to go with the PR that exports the types and leaves the Vitest configuration up to the user.

This also takes care of the case of using jest-extended together with your own additional matchers and supports using omit on the type in case not all of the matchers are in use.

from jest-extended.

Also running into this issue, for now having to drop the jest-extended version 😔

Might need some input from @keeganwitt

I won't be able to get to it this week. But will try to next week

from jest-extended.

Do folks agree that reverting #600 would be a good at least temporary step?

from jest-extended.

This was the test I did with the fix, which seemed to work (though I'm no vitest expert)
https://github.com/keeganwitt/vitest-jest-extended-test

The only thing I'm not sure about is whether this part is actually needed

declare namespace jest {
  interface Matchers<R> {
    toHaveBeenCalledAfter(
      mock: jest.MockInstance<any, any[]> | import('vitest').MockInstance<any, any[]>,
      failIfNoFirstInvocation?: boolean,
    ): R;

    toHaveBeenCalledBefore(
      mock: jest.MockInstance<any, any[]> | import('vitest').MockInstance<any, any[]>,
      failIfNoSecondInvocation?: boolean,
    ): R;
  }
}

from jest-extended.

Same issue here with TS 5.1.3. jest-extended 4.0.0 just got released yesterday with this breaking change and types are broken for me

from jest-extended.

Just FFR - my workaround is to use code as below when I need vitest types rather than jest-extend types

import type { SpyInstance } from 'vitest/dist/index';

from jest-extended.

Sorry for the issue I introduced.

I made those 2 PRs

• #613
• #614

Both of them fixes the issue described by @mlev.

I do not have a perfect solution in mind. Each of the solution comes with advantages and drawbacks.

But in each of them I have trouble fixing the typescript errors

from jest-extended.

On my side I was using jest-extended only for this functionality https://jest-extended.jestcommunity.dev/docs/matchers/Array#toincludesamemembersmembers

But I found out that vitest has this natively with the chai api. So I will probably not be using jest-extended anymore

from jest-extended.

Also running into this issue, for now having to drop the jest-extended version 😔

Might need some input from @keeganwitt

from jest-extended.

I had to resolve it temporarily by applying a patch via patch-package.

File patches/jest-extended+4.0.0.patch:

diff --git a/node_modules/jest-extended/types/index.d.ts b/node_modules/jest-extended/types/index.d.ts
index 16626d3..30474c0 100644
--- a/node_modules/jest-extended/types/index.d.ts
+++ b/node_modules/jest-extended/types/index.d.ts
@@ -1,6 +1,11 @@
 /* eslint-disable @typescript-eslint/no-explicit-any */
 
-interface CustomMatchers<R> extends Record<string, any> {
+// jest-extended overrides the entire vitest module
+// see https://github.com/jest-community/jest-extended/issues/610
+// see types/vitest.d.ts
+export interface CustomMatchers<R> extends Record<string, any> {
   /**
    * Note: Currently unimplemented
    * Passing assertion

File types/vitest.d.ts:

import type { CustomMatchers } from "jest-extended";
import type { Assertion, AsymmetricMatchersContaining } from "vitest";

// jest-extended overrides the entire vitest module, so we need to re-extend it here
// see https://github.com/jest-community/jest-extended/issues/610

declare module "vitest" {
  interface Assertion<T = any> extends CustomMatchers<T> {}
  interface AsymmetricMatchersContaining extends CustomMatchers {}
}

from jest-extended.

I had to resolve it temporarily by applying a patch via patch-package.

File patches/jest-extended+4.0.0.patch:

diff --git a/node_modules/jest-extended/types/index.d.ts b/node_modules/jest-extended/types/index.d.ts
index 16626d3..30474c0 100644
--- a/node_modules/jest-extended/types/index.d.ts
+++ b/node_modules/jest-extended/types/index.d.ts
@@ -1,6 +1,11 @@
 /* eslint-disable @typescript-eslint/no-explicit-any */
 
-interface CustomMatchers<R> extends Record<string, any> {
+// jest-extended overrides the entire vitest module
+// see https://github.com/jest-community/jest-extended/issues/610
+// see types/vitest.d.ts
+export interface CustomMatchers<R> extends Record<string, any> {
   /**
    * Note: Currently unimplemented
    * Passing assertion

File types/vitest.d.ts:

import type { CustomMatchers } from "jest-extended";
import type { Assertion, AsymmetricMatchersContaining } from "vitest";

// jest-extended overrides the entire vitest module, so we need to re-extend it here
// see https://github.com/jest-community/jest-extended/issues/610

declare module "vitest" {
  interface Assertion<T = any> extends CustomMatchers<T> {}
  interface AsymmetricMatchersContaining extends CustomMatchers {}
}

If we were to fix this the same way, this would introduce a new dependency on vitest, which I don't think we want to do.

from jest-extended.

also noticed in x.each types broke, the parameters are not inferred anymore

from jest-extended.

Do folks agree that reverting #600 would be a good at least temporary step?

I agree. In the current state, jest-extended is unusable together with vitest.

However, #614 should solve this issue. Actually

import 'vitest';

is the most important part of this. If I add this line manually, everything starts working again

from jest-extended.

However, #614 should solve this issue. Actually

import 'vitest';

is the most important part of this. If I add this line manually, everything starts working again

Keegan addressed this specifically already, and why the pr is not ideal in it's current state: #610 (comment)

If we were to fix this the same way, this would introduce a new dependency on vitest, which I don't think we want to do.

from jest-extended.

My vote is still for just exporting the types to the CustomMatchers, and providing documentation on how Vitest users can use these to add types themselves.

It is jest-extended afterall. I'm not expecting this package to go out of it's way to support Vitest; but providing an reasonable way of doing so would be much appreciated 👍

from jest-extended.

I agree. It's great we can still use this lib with vitest so a copy and paste of some typings to set it up is no problem.

from jest-extended.

However, #614 should solve this issue. Actually

import 'vitest';

is the most important part of this. If I add this line manually, everything starts working again

Keegan addressed this specifically already, and why the pr is not ideal in it's current state: #610 (comment)

If we were to fix this the same way, this would introduce a new dependency on vitest, which I don't think we want to do.

Yes, we would need to add vitest as a dev dependency. IMO that's OK, but I understand if you don't want that. However, that's actually not everything which would need to be changed in the typings 🙄 see main...lukaselmer:jest-extended:main

At the moment, it's an improvement either way (revert commit + docs, or add dev dependency and merge) 😉

from jest-extended.

Yes, we would need to add vitest as a dev dependency. IMO that's OK, but I understand if you don't want that.

The typings are part of the publishing package, and therefore the imports required for these to work correctly become real dependencies. Without this, consumers that only use jest and not vitest would be forced to use ts options to skip lib checking which is not good to impose on consumers.

So, IMO it's not OK, even though I am a vitest user.

from jest-extended.

I'm not a vitest user. Can someone validate the instructions in the PR I just opened?

from jest-extended.

Works for me using latest vitest and jest-extended! Appreciate the fix 💯

from jest-extended.

Actually, not sure what I'm doing wrong, but expect.toBeOneOf doesnt have a type. I'm using a global vitest setup, and I've followed the steps youve mentioned

from jest-extended.

Actually, not sure what I'm doing wrong, but expect.toBeOneOf doesnt have a type. I'm using a global vitest setup, and I've followed the steps youve mentioned

Did you also add the setup below (already present in doc)?

import { expect } from 'vitest';
import * as matchers from 'jest-extended';

expect.extend(matchers);

from jest-extended.

Yeah it's there

from jest-extended.

Yeah it's there

Could there be some difference between our tsconfigs?

You could also try this instead

/// <reference types="vitest" />

export interface CustomMatchers<R> extends Record<string, any> {
  toHaveBeenCalledAfter(
      mock: jest.MockInstance<any, any[]> | import('vitest').MockInstance<any, any[]>,
      failIfNoFirstInvocation?: boolean,
  ): R;

  toHaveBeenCalledBefore(
      mock: jest.MockInstance<any, any[]> | import('vitest').MockInstance<any, any[]>,
      failIfNoSecondInvocation?: boolean,
  ): R;

  toHaveBeenCalledExactlyOnceWith(...args: unknown[]): R;
}

declare module 'vitest' {
  interface Assertion<T = any> extends CustomMatchers<T> { }
}

from jest-extended.

Oh, I was also using jest-extended v3 to avoid the vitest changes made to the types file. That's another possible difference.

from jest-extended.

I'm gonna go ahead and merge this. We can follow-up with improving the documentation as a follow-up.

from jest-extended.