fix(eslint-plugin): [no-unnecessary-type-parameters] cannot assume variables are either type or value

[Josh-Cena]

PR Checklist

• Addresses an existing open issue: fixes Bug: @typescript-eslint/no-unnecessary-type-parameters: ESLint crashes on invalid syntax instead of reporting error #10088
• That issue was marked as accepting prs
• Steps in Contributing were taken

Overview

I thought it was something in the scope manager but it turned out to be really simple: in setItem<T>(T): T, the variable T has two declarations, and it's both a type and a value. Therefore we can't assume that the type parameters declared aren't also available as values.

[typescript-eslint]

Thanks for the PR, @Josh-Cena!

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	1124f6a
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/66fdd9bfcd5fe80008dc1858
😎 Deploy Preview	https://deploy-preview-10093--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 99 (🟢 up 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.

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 1124f6a. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 2 targets

• nx run-many --target=build --exclude website --exclude website-eslint
• nx run-many --target=clean

---

Sent with 💌 from NxCloud.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 86.03%. Comparing base (2055cfb) to head (1124f6a).
Report is 10 commits behind head on main.

Files with missing lines	Patch %	Lines
...plugin/src/rules/no-unnecessary-type-parameters.ts	0.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #10093   +/-   ##
=======================================
  Coverage   86.03%   86.03%           
=======================================
  Files         428      428           
  Lines       14930    14930           
  Branches     4329     4329           
=======================================
  Hits        12845    12845           
  Misses       1741     1741           
  Partials      344      344           

Flag	Coverage Δ
unittest	86.03% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...plugin/src/rules/no-unnecessary-type-parameters.ts	91.42% <0.00%> (ø)

[bradzacher]

Therefore we can't assume that the type parameters declared aren't also available as values

I think that the rule should probably just bail out of this usecase altogether, rather than trying to make it work.

I think this for two reasons:

(1) realistically it's a SUPER rare case that shouldn't happen in any sane code!
Declaring a parameter that's of the same name as the type parameter is unclear and barely working code.
Additionally the generally accepted naming conventions for parameters is lower case, but the generally accepted naming convention for type parameters is pascal case -- which does mean that it's an even rarer case that you actually use the exact same name even accidentally.

(2) value vs type usages are not the simplest thing to deal with and I doubt that the rule has the logic to handle the distinction.

For example consider the following signatures:

declare function foo<T>(T: string, a: T): typeof T;
declare function foo<T>(T: string, a: typeof T): typeof T;
declare function foo<T>(T: string, a: typeof T): T;
declare function foo<T>(T: string, a: T): T;

The first signature has just 1 usage of the type parameter T and so the rule should report.
Only it wouldn't report unless it has the correct handling to distinguish between type and value references.
The second signature is similarly invalid and should report because there's no usages of the type parameter T.
The third signature is similarly invalid and should report because there's only 1 usage of the type parameter T.

The fourth signature is valid and should be valid in the rule as there is a usage of T as a type in two distinct locations.

However there is also another complicated case for the rule to handle:

declare function foo<T>(T: T, a: string): typeof T;
declare function foo<T>(T: string, a: T): typeof T;

Technically the rule shouldn't report on the first signature here because T is actually used in 2 distinct locations because typeof T === T. However I don't believe that the rule will be able to resolve that relationship properly?

We also can't just add handling or typeof T either because the second signature is valid.

---

So with all that said - I think that we should just opt out of handling any type parameter that's both a type AND a value.
There's so much complexity and the rule should just ignore it as a super rare edge-case that won't happen in real / sane code.

[Josh-Cena]

By "opt out", do you mean to assume that they are used more than once? Currently the rule's behavior is completely valid—it only collects usage of the variable in type positions. Check out the deploy preview: https://deploy-preview-10093--typescript-eslint.netlify.app/play#ts=5.5.2&fileType=.tsx&code=CYUwxgNghgTiAEAzArgOzAFwJYHtVJxwB4AVAPgAoSAueAZwxi1QHMAaeKWkgSlowCeABxA5E8EgG4AUKEiwEKdNjwFi5KrQZNWHLvEEixEvgeGjxU2eGhwkaTLnyJCpSjXqNm7Tv3PHebhk5W0UHFWdXDQ9tbz1uUytreTslR1UXdXdueM8dFlNDCwlgmwV7ZSc1N008uN8TPyNLGSA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6Jge1tiacTJTIAhtEK0ipWsRFCAtonyJoqDJCXQO0SODABfELqA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA&tokens=false

[kirkwaiblinger]

@bradzacher

I doubt that the rule has the logic to handle the distinction.

Looks like it is explicitly checked for....

typescript-eslint/packages/eslint-plugin/src/rules/no-unnecessary-type-parameters.ts

Lines 140 to 148 in 3f02687

	// Neither do references that aren't to the same type parameter,
	// namely value-land (non-type) identifiers of the type parameter's type,
	// and references to different type parameters or values.
	if (
	!reference.isTypeReference ||
	reference.identifier.name !== node.name.name
	) {
	continue;
	}

I think this seems like it was just a straightforward bug on my part in https://github.com/typescript-eslint/typescript-eslint/pull/9900/files, and therefore it makes sense to me to move forward with this fix as is, granted that the rule already passes the proposed edge cases without modification, as @Josh-Cena showed.