Adding @testing-library/jest-dom type definitions

[weyert]

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 adding a new definition:

• The package does not already provide its own types, or cannot have its .d.ts files generated via --declaration
• If this is for an NPM package, match the name. If not, do not conflict with the name of an NPM package.
• Create it with dts-gen --dt, not by basing it on an existing project.
• tslint.json should be present, and tsconfig.json should have noImplicitAny, noImplicitThis, strictNullChecks, and strictFunctionTypes set to true.

If changing an existing definition:

• Provide a URL to documentation or source code which provides context for the suggested changes: <>
• If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.
• If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }.

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.

[typescript-bot]

👋 Hi there! I’ve run some quick performance metrics against master and your PR. This is still an experiment, so don’t panic if I say something crazy! I’m still learning how to interpret these metrics.

Let’s review the numbers, shall we?

These typings are for a package that doesn’t yet exist on master, so I don’t have anything to compare against yet! In the future, I’ll be able to compare PRs to testing-library__jest-dom with its source on master.

Comparison details 📊

Batch compilation
Type count	10421
Assignability cache size	33955
Subtype cache size	0
Identity cache size	3
Language service measurements
Samples taken	64
Identifiers in tests	64
getCompletionsAtPosition
Mean duration (ms)	390.2
Median duration (ms)	394.0
Mean CV	13.7%
Worst duration (ms)	478.2
Worst identifier	element
getQuickInfoAtPosition
Mean duration (ms)	381.2
Median duration (ms)	378.5
Mean CV	14.9%
Worst duration (ms)	481.0
Worst identifier	toHaveValue
System information
Node version	v10.16.1
CPU count	2
CPU speed	2.394 GHz
CPU model	Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz
CPU Architecture	x64
Memory	6.8 GiB
Platform	linux
Release	4.15.0-1052-azure

---

If you have any questions or comments about me, you can ping @andrewbranch. Have a nice day!

[typescript-bot]

@weyert Thank you for submitting this PR!

Because this is a new definition, a DefinitelyTyped maintainer will be reviewing this PR in the next few days once the Travis CI build passes.

In the meantime, if the build fails or a merge conflict occurs, I'll let you know. Have a nice day!

[PranavSenthilnathan]

Aren't these types already being exposed through the package with the d.ts?

[gnapse]

@PranavSenthilnathan if you can, checkout the discussion in testing-library/jest-dom#123. It gives you some context about what we're trying to achieve here.

[sheetalkamat]

This change is not needed. The package can add "types" field to the package and thats the desired way of adding types. Refer to https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/declaration%20files/Publishing.md

[sheetalkamat]

This change is not needed. The package can add "types" field to the package and thats the desired way of adding types. Refer to https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/declaration%20files/Publishing.md

[weyert]

This change is not needed. The package can add "types" field to the package and thats the desired way of adding types. Refer to https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/declaration%20files/Publishing.md

Yes, I understand but we decided to add as a dependency, like the other @testing-library packages. I kindly request to reconsider this decision as this would this library to not have type definitions.

@sheetalkamat Please see this article https://blog.johnnyreilly.com/2019/08/symbiotic-definitely-typed.html for the reasoning for this approach.

@johnnyreilly @sheetalkamat

[johnnyreilly]

Hey @sheetalkamat

This change is not needed. The package can add "types" field to the package and thats the desired way of adding types.

This PR adds types to Definitely Typed which will result in an @types/... package being generated. The @testing-library/jest-dom doesn't want to maintain it's own type definitions and would rather have them maintained via Definitely Typed. To my knowledge the "types" solution via package.json only works for local type definitions that ship with the library. That does apply in this case right now. But this package would like to remove the local types in favour of having them managed via DT. It's a continuation of the work documented in this blog post: https://blog.johnnyreilly.com/2019/08/symbiotic-definitely-typed.html

As far as I can tell, this PR should be safe to merge assuming that my understanding of the desired direction is correct and so I've reopened it. Before we do merge let's be sure that we want this to be the direction for this package. The solution that @sheetalkamat suggested is eminently suitable as an alternative if @gnapse if happy to maintain.

It's a choice; but let's be clear about which choice we want to make. I'm not sure that's entirely explicit as yet. Hopefully the responses to this comment: testing-library/jest-dom#123 (comment) will make it clear the direction that people want to go.

[typescript-bot]

Updated numbers for you here from 61602ba:

These typings are for a package that doesn’t yet exist on master, so I don’t have anything to compare against yet! In the future, I’ll be able to compare PRs to testing-library__jest-dom with its source on master.

Comparison details 📊

Batch compilation
Type count	10421
Assignability cache size	33955
Subtype cache size	0
Identity cache size	3
Language service measurements
Samples taken	64
Identifiers in tests	64
getCompletionsAtPosition
Mean duration (ms)	384.3
Median duration (ms)	379.0
Mean CV	14.5%
Worst duration (ms)	488.1
Worst identifier	toHaveValue
getQuickInfoAtPosition
Mean duration (ms)	368.7
Median duration (ms)	361.3
Mean CV	15.5%
Worst duration (ms)	484.9
Worst identifier	element
System information
Node version	v10.16.1
CPU count	2
CPU speed	2.294 GHz
CPU model	Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz
CPU Architecture	x64
Memory	6.8 GiB
Platform	linux
Release	4.15.0-1052-azure

[typescript-bot]

@weyert One or more reviewers has requested changes. Please address their comments. I'll be back once they sign off or you've pushed new commits or comments. Thank you!

[sheetalkamat]

According to https://github.com/testing-library/jest-dom#usage this you need to have extend-expect to be present that contains the globals

[weyert]

Yes, as this library is extending expect() to have more matchers.

[sheetalkamat]

What I meant was there needs to be a file extend-expect.d.ts that defines all the global declaraitons.

[sheetalkamat]

This is not going to work with import {toBeInTheDocument, toHaveClass} from '@testing-library/jest-dom' as per https://github.com/testing-library/jest-dom#usage

[weyert]

I am not sure how to support this alternative way of using the library with TypeScript. Do we want to support the not typical usage of the library? Any tips how this could be resolved?

By exposing both ways extending the jest namespace and export as a typical type outside the namespace to allow covering this?

[sheetalkamat]

Please read https://github.com/DefinitelyTyped/DefinitelyTyped#how-do-i-write-definitions-for-packages-that-can-be-used-globally-and-as-a-module for details on how to write definitions that are available as module or global

[weyert]

Hello @sheetalkamat, @johnnyreilly. Looks like there is a little change of plan regarding this type definition. The idea now is to keep the type definition in the actual package @testing-library/jest-dom but also define it in DT but the definition living in DT would depend on the @testing-library/jest-dom typescript definiton and just import this one.

Would this be acceptable?

[weyert]

See response of @sheetalkamat for the above question here:
testing-library/jest-dom#123 (comment)

[weyert]

Closing pull request as it's not needed