fix(eslint-plugin): [no-unnecesary-type-assertion] treat unknown/any as nullable #8089
Conversation
|
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. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
fa39a81 to
1f557ae
Compare
|
Yeah great point on the |
|
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. |
|
It is poorly documented and I don't even understand what |
|
I think we need to keep |
|
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. |
PR Checklist
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.