feat(eslint-plugin): [no-unnecessary-type-parameters] initial implementation

[danvk]

PR Checklist

• Addresses an existing open issue: fixes Rule proposal: warn against unnecessary type parameters #3729
• That issue was marked as accepting prs
• Steps in Contributing were taken

Overview

See linked issue. I've incorporated the tests from my blog post and all the existing rules. We sometimes (but not always) agree with them.

I'm pretty happy with how this turned out! The logic winds up being pretty straightforward: count the number of times each type parameter is referenced, whether explicitly or implicitly in an inferred return type. If that's exactly one, then report an issue.

One fun discovery: I always thought that this rule had some unavoidable false positives, e.g. my both function from cartant/eslint-plugin-etc#15. But looking at that again a few years later, I think it's a true positive that can be rewritten to avoid breaking the golden rule:

❌ Incorrect

/**
 * Call two functions with the same args, e.g.
 *
 * onClick={both(action('click'), setState)}
 */
export function both<
  Args extends unknown[],
  CB1 extends (...args: Args) => void,
  CB2 extends (...args: Args) => void,
>(fn1: CB1, fn2: CB2): (...args: Args) => void {
  return function (...args: Args) {
    fn1(...args);
    fn2(...args);
  };
}

✅ Correct

export function both<Args extends unknown[]>(
  fn1: (...args: Args) => void,
  fn2: (...args: Args) => void,
): (...args: Args) => void {
  return function (...args: Args) {
    fn1(...args);
    fn2(...args);
  };
}

🎉

---

Notes from Josh (April 2024): Dan and I chatted and I'm pitching in to help get this to review state. The design is actually more intricate than we'd initially hoped:

• We'd initially hoped to look at AST nodes primarily and use type information to augment inferred types. However, there's so much in the types that can be inferred, the types have to nearly always be checked anyway - so I ended up dropping the AST node checks altogether!
• I had to implement some tricky, rough heuristics around whether type parameter referenced existed in general space (e.g. as types of runtime parameters) vs. in return space (e.g. return types).

The logic is still straightforward: recursively descend into types, kind of like how scope analyzer does in AST-land. But the edge cases were quite tricky.

💖

[typescript-eslint]

Thanks for the PR, @danvk!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

---

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint.

[netlify]

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	94ee0fd
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/667c213d0b1d7c0008797cf0
😎 Deploy Preview	https://deploy-preview-8173--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 97 (🔴 down 3 from production) Accessibility: 100 (no change from production) Best Practices: 92 (no change from production) SEO: 90 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[danvk]

Your tweet about carving out dedicated time to finish this inspired me to carve out some time to understand how it works. It's not what I expected! But I think it's fine for now. See my comments / questions. Some more clarifying comments would be helpful.

[Josh-Cena]

Question: what's the motivation for counting the references to T for the underlying generic type definition? For example, in the case f<T>(): G<T>, I would very much prefer it to be f(): G<unknown> instead, and then I can cast it like f() as G<number>.

[danvk]

Question: what's the motivation for counting the references to T for the underlying generic type definition? For example, in the case f<T>(): G<T>, I would very much prefer it to be f(): G<unknown> instead, and then I can cast it like f() as G<number>.

@Josh-Cena see discussion about return types here: #8173 (review). Depending on G, it's possible that G<T> has meaningfully different behavior than G<unknown>, even when it only appears as a return type.

[JoshuaKGoldberg]

From chats with @bradzacher and @Josh-Cena: we're roughly ready to merge this rule, but it's still somewhat experimental / something-we-haven't-tried-ourselves-before. So instead of putting in strict for now I'll add this notice and file a followup to move to strict.

[JoshuaKGoldberg]

(for posterity: the chats were about adding a notice; I felt icky after the fact about both having a notice and leaving it in strict)

[JoshuaKGoldberg]

OK! I chatted around internally and we're happy to try this out as-is. It's pretty early stage (and pretty different from previous implementations) so we're going to give it a warning notice and leave it out of the strict preset for a bit. Time to start trying it out on our own projects! 🚀

Thanks again for getting this started and working with us throughout the PR @danvk. I'm really excited both about the rule and that we got an excuse to work together! 🙂

[danvk]

Thanks for taking over this PR and getting it merged, @JoshuaKGoldberg! I'm definitely curious to see what sort of feedback we get on it.