jest: Update comparison methods to support BigInt

[D4nte]

As per jestjs/jest#8382

TypeScript 3.2+ supports BigInt with esnext target.
TypeScript 3.8+ supports it with es2020 target.

dtslint is very particular on how the typesVersions
should be handled, hence the code duplication.

• 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 changing an existing definition:

• Provide a URL to documentation or source code which provides context for the suggested changes: feat: BigInt Support jestjs/jest#8382
• 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.
• Include tests for your changes
• If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }. If for reason the any rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.

[typescript-bot]

@D4nte Thank you for submitting this PR!

Code Reviews

Because this is a widely-used package, a DT maintainer will need to review it before it can be merged.

Status

• ✅ No merge conflicts
• ✅ Continuous integration tests have passed
• ❌ A DT maintainer needs to merge changes which affect module config files

Once every item on this list is checked, I'll ask you for permission to merge and publish the changes.

---

Diagnostic Information: What the bot saw about this PR

{
  "type": "info",
  "now": "-",
  "pr_number": 44368,
  "author": "D4nte",
  "owners": [
    "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",
    "regevbr"
  ],
  "dangerLevel": "ScopedAndConfiguration",
  "headCommitAbbrOid": "bb1c089",
  "headCommitOid": "bb1c089d8007f3989dd62f3a93bfce55bd82af0d",
  "mergeIsRequested": false,
  "stalenessInDays": 4,
  "lastCommitDate": "2020-05-14T04:03:10.000Z",
  "lastCommentDate": "2020-05-14T04:03:51.000Z",
  "reviewLink": "https://github.com/DefinitelyTyped/DefinitelyTyped/pull/44368/files",
  "hasMergeConflict": false,
  "authorIsOwner": false,
  "isFirstContribution": false,
  "popularityLevel": "Critical",
  "anyPackageIsNew": false,
  "packages": [
    "jest"
  ],
  "files": [
    {
      "filePath": "types/jest/package.json",
      "kind": "package-meta",
      "package": "jest"
    },
    {
      "filePath": "types/jest/ts3.2/index.d.ts",
      "kind": "definition",
      "package": "jest"
    },
    {
      "filePath": "types/jest/ts3.2/jest-tests.ts",
      "kind": "test",
      "package": "jest"
    },
    {
      "filePath": "types/jest/ts3.2/tsconfig.json",
      "kind": "package-meta",
      "package": "jest"
    },
    {
      "filePath": "types/jest/ts3.2/tslint.json",
      "kind": "package-meta",
      "package": "jest"
    }
  ],
  "hasDismissedReview": false,
  "travisResult": "pass",
  "lastReviewDate": "2020-05-16T18:55:32.000Z",
  "reviewersWithStaleReviews": [],
  "approvalFlags": 2,
  "isChangesRequested": false
}

[typescript-bot]

👋 Hi there! I’ve run some quick measurements against master and your PR. These metrics should help the humans reviewing this PR gauge whether it might negatively affect compile times or editor responsiveness for users who install these typings.

Let’s review the numbers, shall we?

Comparison details 📊

	master	#44368	diff
Batch compilation
Memory usage (MiB)	82.3	82.9	+0.6%
Type count	14711	14711	0%
Assignability cache size	35944	35944	0%
Language service
Samples taken	2553	2553	0%
Identifiers in tests	2553	2553	0%
getCompletionsAtPosition
Mean duration (ms)	380.5	383.2	+0.7%
Mean CV	8.0%	8.3%
Worst duration (ms)	509.6	549.9	+7.9%
Worst identifier	expect	toHaveProperty
getQuickInfoAtPosition
Mean duration (ms)	376.4	378.7	+0.6%
Mean CV	7.8%	8.4%	+7.8%
Worst duration (ms)	485.7	514.2	+5.9%
Worst identifier	arrayContaining	extendedExpect

It looks like nothing changed too much. I won’t post performance data again unless it gets worse.

[D4nte]

How can I see if any of the code maintainers have been notified?

[typescript-bot]

🔔 @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 @regevbr - 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.

[wsmd]

Thanks for the PR, @D4nte!

dtslint is very particular on how the typesVersions
should be handled, hence the code duplication.

The code duplication isn't ideal since we would need to maintain 3 files at the same time moving forward (i.e. any change to be made in the future, we have to ensure that it's reflected in all copies).

Have you considered referencing the main types in the version-scoped files (as opposed to copying them) and adding only the specific overrides needed? It seems that how it's implemented in @types/node (I see they're using // tslint:disable-next-line:no-bad-reference in some places).

[typescript-bot]

@D4nte 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. If you disagree with the reviewer's comments, you can "dismiss" the review using GitHub's review UI. Thank you!

[D4nte]

Thanks for the PR, @D4nte!

dtslint is very particular on how the typesVersions
should be handled, hence the code duplication.

The code duplication isn't ideal since we would need to maintain 3 files at the same time moving forward (i.e. any change to be made in the future, we have to ensure that it's reflected in all copies).

Have you considered referencing the main types in the version-scoped files (as opposed to copying them) and adding only the specific overrides needed? It seems that how it's implemented in @types/node (I see they're using // tslint:disable-next-line:no-bad-reference in some places).

I tried but yarn test was unhappy. Will try again with some inspiration from @types/node.

[typescript-bot]

@wsmd Thank you for reviewing this PR! The author has pushed new commits since your last review. Could you take another look and submit a fresh review?

[sandersn]

@D4ANTE @wsmd is this ready to go? My opinion is that the code-sharing technique is fine -- it technically works even though it's a bit confusing.

[wsmd]

@sandersn I'm planning on taking another look later tonight before final approval, but overall this addresses my last suggestion. Sorry for the wait, @D4nte!

[D4nte]

Yes, ready to go from my point of view. If not, please do mention what you'd like to see changed :)

[typescript-bot]

@wsmd Thank you for reviewing this PR! The author has pushed new commits since your last review. Could you take another look and submit a fresh review?

[wsmd]

Looks good! Thanks for doing this @D4nte!

[typescript-bot]

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