Skip to content
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

Backing out Promise's resolve changes #41497

Closed
DanielRosenwasser opened this issue Nov 11, 2020 · 4 comments
Closed

Backing out Promise's resolve changes #41497

DanielRosenwasser opened this issue Nov 11, 2020 · 4 comments
Labels
Declined The issue was declined as something which matches the TypeScript vision Suggestion An idea for TypeScript

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Nov 11, 2020

In TypeScript 4.1, we've worked on two changes:

The thing that we've seen a lot of is that most large codebases are impacted in some capacity. At Google, 0.26% of "libraries" were impacted by the non-optionality of resolve, and it's a legitimate concern. We've also seen breaks similar things from projects within Microsoft, though we don't have the same sort of holistic view of codebases internally.. the change is relatively mechanical, but it is fairly breaky, and it is fairly common according to the report at #41445.

It is fairly last-minute, but I think there are a few questions which are worth asking:

  • Do these breaks warrant a 2-step release process of allowing void parameters to be optional and then making resolve optional?
  • If so, does this need a back-out?
  • Is a back-out even more dangerous at this point?
  • Will we realistically put the change back in for 4.2?
@DanielRosenwasser DanielRosenwasser added Suggestion An idea for TypeScript In Discussion Not yet reached consensus labels Nov 11, 2020
@weswigham
Copy link
Member

(There's also the option of moving the change behind a flag, and inverting the default of the flag in the future)

@DanielRosenwasser
Copy link
Member Author

It's an option, but it's unclear how we would flag this since it's primarily a lib.d.ts .

@rbuckton
Copy link
Member

I was discussing this with @DanielRosenwasser offline, but 4.1 doesn't introduce the idea of trailing void being optional. That has been a feature since 3.2 (#27522), but only worked for calls, not assignability. #40231 only fixes assignability. If this were a two step process, step one happened a little over two years ago.

@rbuckton
Copy link
Member

It's an option, but it's unclear how we would flag this since it's primarily a lib.d.ts .

We have --strictBindCallApply, although that primarily affects apparent types for functions. I'm not sure there is a good way to do this with a flag, given you can't dynamically change the optionality of a parameter by changing its type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Declined The issue was declined as something which matches the TypeScript vision Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

3 participants