-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Design Meeting Notes, 2/16/2018 #22011
Comments
well, the new conditional types solve type-level type checks. |
Now that error suppression is being discussed, I'd like to propose also adding a compiler flag for reporting unused suppressions. #22021 |
It seems like the discussion on
I'd just like to toss out: at my place of work we would gladly use unclear error codes, if it gave us the ability to suppress errors. Heck, we'd use savage personal insults, as long as it allowed us this functionality. We have a large JS application we're migrating to TS. We'd like to turn on the This will work eventually, but in the meanwhile there is nothing preventing us from introducing new null & implicit any errors. (I mean, there are diligent code reviews, but who trusts humans? That's why we use static type checking in the first place.) TL;DR: we don't care if it's pretty, we just want the compiler to yell at us for bad null handling |
@alexburner what about the current ts-ignore functionality is blocking you from that approach? One possible path would be to build once, write a quick script to insert |
Just the specificity, we don't want to throw the baby out with the bathwater. All of our current TS code compiles fine otherwise, we only want to suppress the |
The real problem (I'm surprised this didn't make it into the notes) is that we generally don't consider a different error message being issued as a significant breaking change. For example, we sometimes add a more-specific error message for certain cases to give a better developer experience. Every error message has its own distinct error code. We don't want people to get into a situation where upgrading from TS X.Y to X.Y+1 yields hundreds of new errors simply because we changed an error message code, or end up doing a bunch of Rube Goldberg work in the checker to issue a "legacy" error message in some cases. |
In this case, we'd be down for that danger! It would still be an improvement over our current situation (and, ideally, we wouldn't be leaning on these "ignores" at some point in the future). But, I do see how this makes things ugly, from a general public perspective. You don't want to be responsible for innocent bystanders receiving new errors during upgrading. And supporting legacy error messages sounds like a pain. Is there any way this could be released as an experimental/volatile feature? Some sort of marketing/positioning that made it clear users are opting in to unpredictable behavior? |
The extent to which we've tried that is basically The rando who shows up on HN or Twitter to trash TypeScript 3.7 because it put hundreds of new errors in his codebase isn't going to disclaim that he had Then he's here on the issue tracker along with everyone else who got opted into a janky build system requesting that we add an Then we need another flag to specify when they don't don't want to not ignore a |
Okayyyy okay okay, I now viscerally understand the pains of supporting an open source project on this scale. Thank you for playing out this thought experiment with me, I will let you be 😅 |
Recursive Conditional Types
#21316 (comment)
A
is assignable toB
inA extends B
) requires evaluatingA
.A
is a conditional type, either branch needs to be evaluated immediately to see if it satisfiesB
. That means you can end up exhausting your instantiation stack.Ignore specific errors with
@ts-ignore
commentsIssue: #19139
PR: #21602
--pretty
?The text was updated successfully, but these errors were encountered: