-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Update no-explicit-any.md #7355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
f66b4e9
Update no-explicit-any.md
ericelliott 2960616
Update no-explicit-any.md
ericelliott fb7adc9
Update no-explicit-any.md
ericelliott 71bcdd9
Update no-explicit-any.md
ericelliott 30eabba
Update packages/eslint-plugin/docs/rules/no-explicit-any.md
ericelliott 4907378
Update packages/eslint-plugin/docs/rules/no-explicit-any.md
ericelliott File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Praise] +1, heh - this existing opening sentence is a bit strong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What isn't dangerous about
any
?It literally opts you out of every single check that TS might provide - there's nothing that isn't dangerous about that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-thinking after reading your #7354 (comment): yeah you're right. I was coming from the perspective that it can be necessary and, when handled carefully, relatively safe. But as you said:
(and the rest of that paragraph)
Marking as resolved, rescinding my +1 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bradzacher I could go deep into the empirical data behind type safety but this isn't the right forum for a debate. I think it's enough to say that there are some useful things that you just can't do in TypeScript without
any
- foundational things like proper function composition (see the code example) which can eliminate a huge amount of code in your application and with it, eliminate all the bugs that may have cropped up in the code that got eliminated. In other words, there are cases where usingany
is a net win for safety, by a huge margin.In this particular case, it's more dangerous to think of
any
as a dangerous error than it is to allow it because of the danger it saves us from.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree that
any
is safe anywhere.I get that there are cases that you can't type with TS and are stuck using an
any
or ts ignores - but that doesn't make the usecases safe.As mentioned in the issue - the only reason your example code is "safe" is because you've hidden the any with an explicit annotation. Had you forgotten the explicit annotation then your code would be in an unsafe state. This approach is simply not scalable though - in small teams it can be sufficient to find and catch in code reviews and thus "make things safe" - but at scale you can't rely on such tribal knowledge and the pattern quickly devolves into an unsafe mess.
Using
any
is unsafe. Not potentially - it just is.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That dogmatic opinion is not supported by evidence. If you have evidence to support your statement, please supply it. Otherwise, I refer you to the provably true statement: "[function composition] can eliminate a huge amount of code in your application and with it, eliminate all the bugs that may have cropped up in the code that got eliminated." In other words, whether or not static types actually have any causal relationship with bug density (a statement which lacks empirical support), we can say with objective certainty, in the specific case of function composition,
any
can be empirically shown to reduce the likelihood of bugs by reducing the surface area of code - which, regardless of bug density, will reduce the total amount of code that bugs could appear in, and hence, reduce the total number of bugs over-all.Empirical Evidence:
This paper specifically looking at TypeScript vs JavaScript found:
any
is "dangerous".The paper concludes that while TypeScript has benefits like code quality, it does not directly reduce bugs versus JavaScript in this sample. The perceived advantage of type safety for bug prevention was not observed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're thinking of pointing to the widely cited "To Type or Not to Type" whose conclusions were specifically rejected by the last article I mentioned above, you should know the original "To Type or Not to Type" article is the primary source I used to show a very small relationship between static types and bug density in The TypeScript Tax because the study showed that "specification errors caused about 78% of the publicly classified bugs studied on GitHub". This implies that type safety cannot be the primary safety net that you use to prevent bug defects, and after applying other safety measures (design review, tdd, code review) the number of remaining bugs is very small, so even factoring for a further 20% bug reduction from TypeScript (which the paper did not achieve, even knowing the root cause of the bugs studied and specifically trying to solve for them using TypeScript typings), the difference in total bugs found is quite small, relatively speaking:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last point: The back-and-forth in THIS PR about attempts to improve type safety using features like generics to try to make composition type safe reveals examples where the attempt to eliminate
any
in the type definition actually introduced bugs, breaking the type checking forcompose
andpipe
by making the types more restrictive than they should have been, or leading to incorrect typings for the functions.This supports my assertion that sometimes, just using
any
is safer than trying to remove it from your code.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're talking past each other. The following points are ones we seem to agree on:
any
is sometimes necessary in TypeScript to fully represent type signatures not representable in its type system: agreed ✅any
should not be used when a more appropriate type representation is available: agreed ✅ with the caveat that we might not agree on what is more appropriate whenany
outside of limited necessary uses reduce TypeScript's usefulness: agreed ✅ because by definition, features such as go-to-definition and property name checking are turned off onany
sThe following two opinions are considered canon in this repository. It would be a waste of time to debate them here, as they're generally-accepted TypeScript best practices and discussing them would quickly devolve into huge discussions that likely won't change anybody's mind:
any
is dangerous: even if it's necessary, it's very easy to get wrongas
type assertions is sometimes necessary too, but they're also -to a lesser extent- dangerousThe main contentious point seems to be the intent and wording around whether to use
any
as a backup / last resort. Yes, there are cases where usingany
is better than an incorrect type description. If (or, I hope, when) we do take in a PR mentioning that, it'll probably end up being 2-3 sentences at most. We don't need to pull in all of programming and paradigm type theory to discuss those 2-3 sentences.I'll post a root comment on this PR. edit: #7355 (comment)