Add custom type to DefinitelyTyped
RicardoJBarrios opened this issue ยท 15 comments
Feature Request
Description:
When use Jest
and jest-expect-message
with Typescript the compiler always display an error because Expect interface only accept one argument in the definition from DefinitelyTyped, but tests works as expected.
Possible solution:
For a temporal workaround I have added <T = any>(actual: T, customMessage?: string): Matchers<T>;
to the Expect
interface in @types/jest/index.d.ts
, but it could be added as an extension to DefinitelyTyped
.
Could this be added to this library so that when it is imported it extends jest's types?
Hey @RicardoJBarrios I don't use Typescript, is it possible to do as @sabrehagen suggested and add the type definition to this project and override Jest's types? Happy to accept any help with this :)
I tried placing the below snippet in node_modules/jest-expect-message/typings.d.ts
and adding the "types": "typings.d.ts"
field to the jest-expect-message
package.json
but the merged declaration was not picked up. Any idea on how to support this 'unofficial' type through this package?
declare namespace jest {
interface Expect {
<T = any>(actual: T, message?: string): Matchers<T>;
}
}
As far as I know there is no (or at least, elegant) way, to override an existing type.
My suggestion is: in setup script, instead of overwrite global.expect
, use another name e.g. global.expectWithMsg
.
It basically changes nothing.
import withMessage from 'jest-expect-message/dist/withMessage'
global.expectWithMsg = withMessage(expect)
then declare your type anywhere else within a .d.ts
:
declare const expectWithMsg: <T>(actual: T, msg: string) => Matchers<T>
For anyone looking for a quick & clean workaround -- I patched jest typings with patch-package, to be placed under patches/@types/jest+23.3.13.patch
patch-package
--- a/node_modules/@types/jest/index.d.ts
+++ b/node_modules/@types/jest/index.d.ts
@@ -448,7 +448,9 @@ declare namespace jest {
*
* @param actual The value to apply matchers against.
*/
- <T = any>(actual: T): Matchers<T>;
+ // Patched declaration to support jest-expect-message
+ // TODO monitor https://github.com/mattphillips/jest-expect-message/issues/1 for an actual solution
+ <T = any>(actual: T, customMessage?: string): Matchers<T>;
/**
* Matches anything but null or undefined. You can use it inside `toEqual` or `toBeCalledWith` instead
* of a literal value. For example, if you want to check that a mock function is called with a
@sabrehagen Your type declaration seems fine to me.
jest-extended
also provide their type declaration this way and it seems to work for them.
Maybe /// <reference types="jest" />
somehow tells TS to merge declarations?
This is what worked for me:
Create @types
folder in your node project
put there jest-expect-message.d.ts
:
export {}
declare global {
namespace jest {
interface Expect{
<T = any>(actual: T, message:String): Matchers<T>;
}
}
}
Here is a sample project: https://github.com/mike-d-davydov/typedef-jest-expect-message .
That is pretty much it. I am also trying to push this definition to Definitely Typed: DefinitelyTyped/DefinitelyTyped#34890. Please kindly let me know if there are any comments/suggestions how to improve.
Will update when done.
@mattphillips , please kindly take a look: DefinitelyTyped/DefinitelyTyped#34890. It seems like I may need an author approval for this to get through... Thanks!
Thanks @mike-d-davydov, seems to work out of the box now by installing:
yarn add --dev @types/jest-expect-message
Thanks for pushing it to DefinitelyTyped repo!
Works for me! Guess this issue can be closed?
Great, it might be a good idea to add this to the main readme.
@mike-d-davydov should not the message field be optional?
Like so:
declare namespace jest {
interface Expect {
<T = any>(actual: T, message?: string): Matchers<T>;
}
}
@mattphillips are you still maintaining this package?
I've added a typescript setup instructions to the readme: https://github.com/mattphillips/jest-expect-message#configure-typescript and defined the types as part of this library so will go ahead and close this.