fix(eslint-plugin): [no-unnecesary-type-assertion] treat unknown/any as nullable

[Josh-Cena]

PR Checklist

• Addresses an existing open issue: fixes [no-unnecessary-type-assertion] False negative on unknown! #1082
• That issue was marked as accepting prs
• Steps in Contributing were taken

Overview

Please tell me if I missed anything, but it turns out we aren't using either of the options of isNullableType, and I'm not sure if they really matter, so I've removed them. Please let me know if they need to be kept for compatibility (I don't think they are part of the API surface but who knows)?

This change also touches several other rules, but their tests pass anyway, and from a rough look there shouldn't be extra errors.

[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	99c1828
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/65a05c889affbb0008f44b40
😎 Deploy Preview	https://deploy-preview-8089--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 92 (🔴 down 4 from production) Accessibility: 100 (no change from production) Best Practices: 92 (no change from production) SEO: 98 (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.

[JoshuaKGoldberg]

Yeah great point on the type-utils change... I don't know myself 😄 filed #8093.

[bradzacher]

The package is part of our public API. We need to keep backwards compatibility.

Being poorly (or not at all 😅) documented doesn't change that. The only parts of exported packages that we may break at any time are explicitly marked as such in our package.json exports.

[Josh-Cena]

It is poorly documented and I don't even understand what isReceiver is supposed to do. Can we keep isReceiver in the type but make it do nothing?

[JoshuaKGoldberg]

I think we need to keep isReceiver in the type and what it's doing now at runtime 😞 but a good followup for v7 would be to remove it.

[bradzacher]

It's been a long long time since #478 so I can't remember the full context for why it was added.

I believe the idea was that in a receiving location (eg the assignment target - the thing that's on the "receiving" end of an assignment) the util would specifically treat any as a "null". Based on the type flags any isn't null IIRC so it needs separate handling.

I think I went in a different direction and so the flag wasn't ever used.