-
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
Allow arbitrary catch clause type annotations #52280
Allow arbitrary catch clause type annotations #52280
Conversation
@typescript-bot pack this |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
9386f12
to
db0c9b0
Compare
db0c9b0
to
64cc18f
Compare
Semantic tokens! shakes fist |
@typescript-bot pack this |
Heya @jakebailey, I've started to run the tarball bundle task on this PR at 4368a4a. You can monitor the build here. |
Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
4368a4a
to
516267c
Compare
I posted this because it was easy after #52240, but per design meeting it seems that this feature isn't palatable (which is totally fair!) especially in the context of upcoming ES pattern matching proposals; closing. |
Fixes #20024
Playground
This is a follow-up to #52240 to exercise my comment in #52240 (comment), pulled into a PR for design meeting demoing.
The actual change is db0c9b0 (i.e. deletions only!), the rest is #52240 as it's not merged in main.
This probably conflicts with #13219 somehow, but I expect that the code in #52240 and this PR that grabs the type for the catch clause would just be updated. That or if we do something like #51390 this should still compose (as it's just another "default" implicit annotation).