expect.extend: not possible to correctly extend corresponding TypeScript types

[NaridaL]

🐛 Bug Report

When extending expect

import expect from "expect"
expect.extend({
  toWorkProperly(received: number, actual: number) {
    return {pass:true}
  }
})

it should be possible to extend the corresponding types:

declare module "expect" {
  interface Matchers<R> {
    toWorkProperly(actual: number): void
  }
}

instead you get

To Reproduce

see above

Expected behavior

There should be no error and proper typechecking.

The reason for the issue, is that expect doesn't actually export the Matchers interface which expect() returns, but rather a sub-interface. See https://github.com/SimenB/jest/blob/master/packages/expect/src/index.ts#L426 .

Unfortunately, it isn't possible to do the right thing directly here, i.e., you can't re-export an interface in a namespace. The quick option would be to move the Matchers declaration directly into the namespace instead of importing it from './types'. The proper solution would probably be to use a proper ES export for expect.

Link to repl or repo (highly encouraged)

repl.it link clicky clicky

envinfo

 npx envinfo --preset jest
npx: installed 1 in 4.202s

  System:
    OS: Linux 5.4 Debian GNU/Linux 9 (stretch) 9 (stretch)
    CPU: (4) x64 Intel(R) Xeon(R) CPU @ 2.30GHz
  Binaries:
    Node: 12.18.3 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.6 - /usr/local/bin/npm
  npmPackages:
    jest: ^26.5.3 => 26.5.3 

 

[SimenB]

Yep, we need to figure out a good story for extending matchers for DefinitelyTyped/DefinitelyTyped#44365 (comment). I haven't spend any time on trying to come up with a good solution for it. We need to both support importing from expect like you do in the OP and import {expect} from '@jest/globals'. Would love some help with coming up with a good solution for this!

[NaridaL]

@SimenB is changing the main export for jest an option? This would be a breaking change for expect. For users either not importing expect at all (relying on globals), or importing it from @jest/globals, it shouldn't require any changes. I assume these are the majority of cases.

This would make extending easily possible. It would also simplify this package. Merging the types and implementation (which are currently separate) might also be possible.

[ajubin]

Hi,

I've encountered the same situation, it seems that the problem is a typescript problem with Declaration Merging. (see more here microsoft/TypeScript#26660 (comment))

I've create a jest.d.ts file with following content.

What worked for me

declare namespace jest {
  interface Matchers<R> {
    toWorkProperly(a: number): R;
  }
}

and

declare global {
  namespace jest {
    interface Matchers<R> {
      toWorkProperly(a: number): R;
    }
  }
}

export {};

What doesn't work

declare global {
  namespace jest {
    interface Matchers<R> {
      toWorkProperly(a: number): R;
    }
  }
}

and

declare namespace jest {
  interface Matchers<R> {
    toWorkProperly(a: number): R;
  }
}

export {};

I don't understand precisely the root cause, it seems to be linked to how ts handles modules and types files;

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.