Remove types for Jest modules

[SimenB]

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).

If removing a declaration:

• If a package was never on DefinitelyTyped, you don't need to do anything. (If you wrote a package and provided types, you don't need to register it with us.)
• Delete the package's directory.
• Add it to notNeededPackages.json.

Jest 24.3.0 has been released, and is completely rewritten to TypeScript, and distributes types. There might be subtle differences between the ones in this repo and the official ones, but I'm hopeful people will PR us the changes they need 🙂

Not sure what this means for

DefinitelyTyped/types/jest/index.d.ts

Line 24 in 442b0dd

/// <reference types="jest-diff" />

Does it need a package.json now?

EDIT: CI failed without it, so added one

One thing to note is that expect also has typings, but the expect typings in this repo is for https://github.com/mjackson/expect, not the one from jest. However, the expect typings do not include any actual matchers, so we should fix that first

[SimenB]

Oh btw, @types/jest itself is left alone. It could maybe import submodules (there's a lot of duplication there), but we're not ready to distribute a typings file with the globals etc. So it should not be considered deprecated quite yet 🙂

[typescript-bot]

@SimenB Thank you for submitting this PR!

🔔 @jmreidy @merrywhether @NoHomey @jwbay @asvetliakov @alexjoverm @epicallan @ikatyang @wsmd @JamieMason @douglasduteil @ahnpnl @JoshuaKGoldberg @UselessPickles @r3nya @Hotell @sebald @andys8 @antoinebrault @lifeiscontent @myabc @theutz @nickmccurdy - 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.

[SimenB]

@sandersn I'm a bit out of my depth on the CI failure 😬

[sandersn]

@SimenB You need to clone Microsoft/types-publisher and add expect to dependenciesWhitelist.txt. I'll merge it and publish a new version of types-publisher. Then CI will pass on a re-run.

npm install @types/jest now includes expect as a dependency, which could run code on install. We don't want to add dependencies without thinking about them first.

[SimenB]

Cool, thanks! microsoft/types-publisher#589

[sandersn]

@SimenB OK, I re-ran CI and it looks like there are a couple of errors but they seem to be more to do with linting and correct versions of expect now.

[SimenB]

The errors confuse me.

jest/index.d.ts(358,50): error TS2694: Namespace 'expect' has no exported member 'MatcherState'.

https://unpkg.com/expect@24.3.0/build/index.d.ts

I also copied this file into a project of mine and it worked

[SimenB]

Is the tester confused due to https://github.com/DefinitelyTyped/DefinitelyTyped/blob/abbd93ac8dac81fa531e52676dc9b119630fd016/types/expect/index.d.ts being a thing?

[typescript-bot]

@SimenB The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

[sandersn]

Yes. It looks in ../expect before looking for node_modules/expect, because of typeRoots (or baseUrl?) in tsconfig.json, which is by design.

@types/expect looks very out of date and expect ships its own types now. I guess that means you should remove @types/expect too.

I've been meaning to do a cleanup run to remove all @types packages that have source packages with types, but I haven't had a chance yet.

[SimenB]

Should make the expect types better first (they don't have the matchers). I'll do that, then come back to you 🙂

[typescript-bot]

@SimenB I haven't seen anything from you in a while and this PR currently has problems that prevent it from being merged. The PR will be closed tomorrow if there aren't new commits to fix the issues.

[SimenB]

New release of expect has the matchers now, so I've updated this

[typescript-bot]

@SimenB The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

[SimenB]

A bunch of TS1192: Module '"/home/travis/build/DefinitelyTyped/DefinitelyTyped/types/jest/node_modules/jest-diff/build/index"' has no default export. which is correct - it's a export =. How can I fix that?

[sandersn]

@SimenB All the ones I saw looked like this:

../jest/node_modules/jest-matcher-utils/build/index.d.ts(7,8): 
error TS1192: 
Module '".../DefinitelyTyped/types/jest/node_modules/jest-diff/build/index"' has no default export

which indicates that jest-matcher-utils expects jest-diff to have export default instead of export =, which is the case (see the code below). Probably jest-matcher-utils needs to be updated to use (1) import jestDiff = require('jest-diff') or (2) set "esModuleInterop": true.

I guess that everybody who uses jest-matcher-utils in Typescript without esModuleInterop is seeing this error right now, because neither types are DT types.

// @Filename: jest-diff/built/index.d.ts
import { DiffOptions as JestDiffOptions } from './types';
declare function diff(a: any, b: any, options?: JestDiffOptions): string | null;
declare namespace diff {
    type DiffOptions = JestDiffOptions;
}
export = diff;

// @Filename: jest-matcher-utils/build/index.d.ts
import jestDiff, { DiffOptions } from 'jest-diff';

[SimenB]

Aha, we use "esModuleInterop": true indeed.

https://github.com/facebook/jest/blob/bdeb5af8ce1cb8e372d4eb51612f711a2979e572/tsconfig.json#L23

What's preferred, Jest changing to import blah = require() or changing config here?

Potentially, we could wait until Jest 25 where we can make breaking changes to the export and use actual ES module exports instead of the hacky half-solution we have now to keep CJS compat

[sandersn]

Well, d.ts files that ship to customers should not assume that they will have "esModuleInterop": true, so the safe option is to use import = require.

[typescript-bot]

@SimenB To keep things tidy, we have to close PRs that aren't mergeable but don't have activity from their author. No worries, though - please open a new PR if you'd like to continue with this change. Thank you!

[despairblue]

@SimenB Hey, what's the state on this? We're hitting exactly what was described here: #33705 (comment)

Using esModuleInterop actually leads to hundreds of other errors with other dependencies:

Type originates at this import. A namespace-style import cannot be called or constructed, and will cause a failure at runtime. Consider using a default import or import require here instead.

[SimenB]

We'll be changing imports and exports to be esm for jest 25

[despairblue]

@SimenB Thanks, for the time being we migrated all our project to use esModuleInterop and allowSyntheticDefaultImports.

Is there an issue for this that I can subscribe to?

[SimenB]

Resurrected in #41837