[jest] add mock.getMockImplementation type

[regevbr]

Please fill in this template.

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Add or edit tests to reflect the change. (Run with npm test.)
• Follow the advice from the readme.
• Avoid common mistakes.
• Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:

If changing an existing definition:

• Provide a URL to documentation or source code which provides context for the suggested changes: missing docs for getMockImplementation of the mock api jestjs/jest#9735

[regevbr]

Please note that I fixated the dependencies as newer version (starting 25.2.0) of jest are using new typescript feature import type which was introduced in 3.8 and not compatible with older typescript versions

[typescript-bot]

@regevbr Thank you for submitting this PR!

🔔 @NoHomey @jwbay @asvetliakov @alexjoverm @epicallan @ikatyang @wsmd @JamieMason @douglasduteil @ahnpnl @JoshuaKGoldberg @UselessPickles @r3nya @Hotell @sebald @andys8 @antoinebrault @favna @gstamac @ExE-Boss @quassnoi @Belco90 @tonyhallett @ycmjason @devanshj @pawfa - please review this PR in the next few days. Be sure to explicitly select Approve or Request Changes in the GitHub UI so I know what's going on.

If no reviewer appears after a week, a DefinitelyTyped maintainer will review the PR instead.

[jwbay]

Thanks for leaving a note about the version pinning -- it's unfortunate, but I don't see a way around it at the moment.

[typescript-bot]

A definition owner has approved this PR ⭐️. A maintainer will merge this PR shortly. If it shouldn't be merged yet, please leave a comment saying so and we'll wait. Thank you for your contribution to DefinitelyTyped!

[typescript-bot]

I just published @types/jest@25.1.5 to npm.

[berickson1]

The version pinning introduced here prevents me from updating to the latest @types/jest since we're enforcing that there aren't duplicate entries in our yarn.lock. We're using a newer version of jest-diff and pretty-format than specified in pacakge.json
I'm assuming this was problematic for building these types? Can you fix the devDependencies version at a lower version to allow for local development? This would allow consumers to pull a newer versions by restoring the carets in dependencies

[regevbr]

@berickson1 what you are asking for will cause all users of this package that use typescript version lower than 3.8 to get compilation / typings issues.

I don't mind increasing the min ts version to 3.8 as I'm always using the latest version but that will mean that a lot of user will not be able to get new typings updates for this package.

Also, in my humble opinion, your issue is very nish and affecting 5 millions weekly downloads for it feels like a stretch.

@jwbay what do you think? do you want to get other maintainers involved here?

p.s

@berickson1 I'm interested why do you impose such restrictions?

[berickson1]

If someone is using an old version of typescript and already includes jest-diff in their bundle, they're likely already pinned to a compatible version that works with older versions of typescript. Bumping to the latest @types/jest wouldn't break anything. If not, they can do it manually in their own package.json, (not perfect but not the end of the world) I don't think this is going to break things for most people.

I've seen a bunch of bundle size bloat with packages being double-included via webpack when there's conflicting versions. In this case it probably would shake out right, but for examples I've seen libraries pin to specific versions of lodash, so webpack would bundle lodash twice, once for usage only in call-sites from the "offending" library and once for the rest of the app. In the case of @types it wouldn't be bundled, but could result in this old version being resolved if there was nothing more specific listed by package dependencies.

[regevbr]

@berickson1 I have read up a bit on the matter after your first message. I get why it is needed when using webpack or a like. I'm coming from server side where the matter is of less importance.

What you are suggesting will not help. The reason being that if someone installs a fresh copy of this package, and they don't have jest-diff, npm/yarn will install the latest version of jest-diff which will break their typings.

The only way for them to solve the issue is to manually install or write a specific resolve to pin those libraries. It will take an average developer some time to realize how to fix the matter and will cause frustration.

My suggestion to you for now is to ignore dev dependencies in your dedupe restrictions as they are not relevant to the use case your are protecting yourself against...

[berickson1]

I'd suspect that if someone is adding a fresh copy of this package for the first time, they're probably in a new or relatively new repo, thus likely using a new version of typescript that wouldn't have this issue.

FWIW it looks like jest-diff worked around this issue in 25.2.7 and later, so I think this can actually be fixed by bumping to ^25.2.7 (jestjs/jest@d4057ce#diff-71ab3b0daed0524930a50a1e724b5677)

I don't believe that webpack picks and chooses what to bundle based on if it's in devDependencies or not unfortunately :(

[regevbr]

That's great that they addressed it, but they still impose a minimum of 3.4 ts version.
Can you draft a quick pr and the maintainers will take a look at it?

[GerkinDev]

This definition is wrong. According to https://github.com/facebook/jest/blob/master/packages/jest-mock/src/index.ts#L51, this should be getMockImplementation(): ((...args: Y) => T) | undefined;. I think you just missed a couple of parenthesis.

[tonyhallett]

@GerkinDev I wouldn't trust all the type definitions you see on jest site.

[GerkinDev]

@tonyhallett this isn't from jest site, but from source code type definitions. Moreover, in real use cases, if actual implementation is not defined, it returns undefined, not a function with same arity that may return undefined.

Anyway, I've PR: #50377

[tonyhallett]

@GerkinDev I was referring to the jest source code type definitions. My comment was in case you were attempting to match theirs without reading the source code.

According to https://github.com/facebook/jest/blob/master/packages/jest-mock/src/index.ts#L51

Although the jest type definition has getMockImplementation(): Function | undefined;

But
https://github.com/facebook/jest/blob/7430a7824421c122cd07035d800d22e1007408fa/packages/jest-mock/src/index.ts#L622

f.getMockImplementation = () => this._ensureMockConfig(f).mockImpl;

Also see jestjs/jest#9061

Regarding getMockImplementation, I think that's undocumented and should not be used

So your change to

getMockImplementation(): ((...args: Y) => T) | undefined;

in #50377 seems incorrect to me.

[GerkinDev]

Given

f.getMockImplementation = () => this._ensureMockConfig(f).mockImpl;

https://github.com/facebook/jest/blob/7430a7824421c122cd07035d800d22e1007408fa/packages/jest-mock/src/index.ts#L622

This calls

private _ensureMockConfig<T, Y extends Array<unknown>>(
    f: Mock<T, Y>,
  ): MockFunctionConfig {
    let config = this._mockConfigRegistry.get(f);
    if (!config) {
      config = this._defaultMockConfig();
      this._mockConfigRegistry.set(f, config);
    }
    return config;
  }

https://github.com/facebook/jest/blob/7430a7824421c122cd07035d800d22e1007408fa/packages/jest-mock/src/index.ts#L432-L441

If there is no config, it inits a new one with

  private _defaultMockConfig(): MockFunctionConfig {
    return {
      mockImpl: undefined,
      mockName: 'jest.fn()',
      specificMockImpls: [],
      specificReturnValues: [],
    };
  }

https://github.com/facebook/jest/blob/7430a7824421c122cd07035d800d22e1007408fa/packages/jest-mock/src/index.ts#L454-L461

where mockImpl is undefined.

Back in your sample

f.getMockImplementation = () => this._ensureMockConfig(f).mockImpl;

https://github.com/facebook/jest/blob/7430a7824421c122cd07035d800d22e1007408fa/packages/jest-mock/src/index.ts#L622

it's actually the mockImpl property that is returned.

I maintain my PR and am even more sure of it.

---

About jestjs/jest#9061, in that case, the type definition should either be removed or correct. An existing incorrect type definition just makes no sense.

[GerkinDev]

Please continue the conversation in #50377. I'll re-post this comment, and I think we should continue there.