[eslint] Enhance Rule.NodeListener type

[acid-chicken]

From #25399 (comment)

This change refines NodeListener type. It removes a necessity for useless type assertion inside of the function of RuleModule.create.

I'm newbie with DefinitelyTyped so I'm sorrry if the patch like this shouldn't be sent.

[typescript-bot]

@acid-chicken Thank you for submitting this PR! I see this is your first time submitting to DefinitelyTyped 👋 — I'm the local bot who will help you through the process of getting things through.

This is a live comment which I will keep updated.

1 package in this PR

• eslint on npm, on unpkg

Code Reviews

Because you edited one package and updated the tests (👏), I can help you merge this PR once someone else signs off on it.

Status

• ✅ No merge conflicts
• ✅ Continuous integration tests have passed
• ❌ Most recent commit is approved by type definition owners or DT maintainers

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

Inactive

This PR has been inactive for 31 days — it is considered abandoned!

---

Diagnostic Information: What the bot saw about this PR

{
  "type": "info",
  "now": "-",
  "pr_number": 45821,
  "author": "acid-chicken",
  "owners": [
    "pmdartus",
    "j-f1",
    "saadq",
    "JasonHK",
    "bradzacher"
  ],
  "dangerLevel": "ScopedAndTested",
  "headCommitAbbrOid": "3c01315",
  "headCommitOid": "3c013156a77c920950f9314448fd4352b561a1f0",
  "mergeIsRequested": false,
  "stalenessInDays": 31,
  "lastPushDate": "2020-08-22T04:23:52.000Z",
  "lastCommentDate": "2020-07-01T18:23:25.000Z",
  "maintainerBlessed": false,
  "reviewLink": "https://github.com/DefinitelyTyped/DefinitelyTyped/pull/45821/files",
  "hasMergeConflict": false,
  "authorIsOwner": false,
  "isFirstContribution": true,
  "popularityLevel": "Popular",
  "newPackages": [],
  "packages": [
    "eslint"
  ],
  "files": [
    {
      "path": "types/eslint/eslint-tests.ts",
      "kind": "test",
      "package": "eslint"
    },
    {
      "path": "types/eslint/index.d.ts",
      "kind": "definition",
      "package": "eslint"
    }
  ],
  "hasDismissedReview": false,
  "ciResult": "pass",
  "reviewersWithStaleReviews": [
    {
      "reviewedAbbrOid": "0909c3e",
      "reviewer": "bradzacher",
      "date": "2020-08-03T15:49:42Z"
    },
    {
      "reviewedAbbrOid": "178e839",
      "reviewer": "bradzacher",
      "date": "2020-07-01T18:23:33Z"
    }
  ],
  "approvalFlags": 0,
  "isChangesRequested": false
}

[typescript-bot]

🔔 @pmdartus @j-f1 @saadq @JasonHK @bradzacher — 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.

[danger-public]

Inspecting the JavaScript source for this package found some properties that are not in the .d.ts files.
The check for missing properties isn't always right, so take this list as advice, not a requirement.

eslint (unpkg)

was missing the following properties:

1. linter

Generated by 🚫 dangerJS against 3c01315

[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	#45821	diff
Batch compilation
Memory usage (MiB)	42.2	52.9	+25.4%
Type count	4569	11742	+157%
Assignability cache size	1109	1550	+40%
Language service
Samples taken	1716	1716	0%
Identifiers in tests	1716	1716	0%
getCompletionsAtPosition
Mean duration (ms)	100.9	95.1	-5.8%
Mean CV	11.7%	12.0%
Worst duration (ms)	177.1	170.8	-3.6%
Worst identifier	desc	getFirstTokensBetween
getQuickInfoAtPosition
Mean duration (ms)	101.2	95.4	-5.7%
Mean CV	12.1%	12.4%	+2.7%
Worst duration (ms)	186.5	164.9	-11.6%
Worst identifier	extensions	getTokensBefore

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

[bradzacher]

I don't think this kind of conditional logic is a good idea
In my experience, creating types dynamically like this over large sets (ESTree.Node is a union of 70 interfaces with 68 distinct type's) can easily cause OOMs in TS
microsoft/TypeScript#30473

This is evidenced by the above typescript-bot perf check which lists the memory usage as being 25% higher.

When I dumped this into a local repo, vscode's typescript integration paused for a few seconds whilst it computed the types.

The only thing that I've found to work efficiently is to list out every single key manually:
https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/experimental-utils/src/ts-eslint/Rule.ts#L247-L424

[typescript-bot]

@acid-chicken 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!

[typescript-bot]

@acid-chicken I haven't seen any activity on this PR in more than 3 weeks, and this PR currently has problems that prevent it from being merged. The PR will be closed in a week if the issues aren't addressed.

[typescript-bot]

@bradzacher 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?

[typescript-bot]

@acid-chicken The CI build failed! Please review the logs for more information.

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

[typescript-bot]

@acid-chicken Unfortunately, this pull request currently has a merge conflict 😥. Please update your PR branch to be up-to-date with respect to master. Have a nice day!

[typescript-bot]

I just published @types/eslint@7.2.3 to npm.