You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This document outlines our focused tasks for TypeScript 3.9, as well as some of the discussion that explains how/why we prioritized certain work items. Nothing is set in stone, but we will strive to complete them in a reasonable timeframe.
For those following the issue and the listed features, we noticed that a lot of code was being impacted by awaited and we've decided that we need to back out the feature to ensure that we can roll it out more smoothly later on. Had we caught some of the errors sooner (see #37560), we might've gotten a better hint around some more of the impact, but even then we've just hit more stuff doing offhand experiments with public repos. Since the PR, we've seen
We considered keeping awaited in and pulling it back out if the issues seem insurmountable, but this seems like an unfair amount of churn to impose on users, especially since the fixes aren't necessarily backwards-compatible. Asking users to use awaited and then remove it if we think it's not working out would be a waste of time for everyone.
We also considered pushing back the beta another week. Adding delays for a feature isn't something we want to start doing, especially because "fixing" a feature takes an indefinite amount of time with enough unknown unknowns. In the worst-case scenario, a bunch of fixes followed by a total rollback of a feature would delay our releases even further.
So the course of action we're taking is:
Delay the beta by another day or two.
Back out the changes and run a bunch of tests to ensure nothing else regresses (including another round of validation on the Visual Studio side just to be safe).
Revisit the awaited type for a later version.
I think this is the most ideal outcome. By not rushing this feature, we'll have a much better handle on it and its impact. 3.9 beta won't be delayed any further, and we'll still have a reasonable amount of time for feedback before the RC for other features.
Type system shouldn't implicitly create awaited types by default. Creating awaited types by Promise functions and methods and async/await operators obviously breaks existing code. So you should provide the stricter type inference and the lib.d.ts using awaited operator only when a flag is enabled.
Activity
LittleStoney commentedon Mar 5, 2020
Thanks
ExE-Boss commentedon Mar 5, 2020
The current
awaitedtype operator PR is #35998.masx200 commentedon Mar 8, 2020
#35392
#20469
This issue has not been resolved for a long time since the question was asked.
Support JSX fragments with jsxFragFactory compiler option and jsxFrag pragma
xiaoxiangmoe commentedon Mar 10, 2020
Is it possible to support
mjs/cjsin ts 3.10?Jack-Works commentedon Mar 10, 2020
ZHAO Jin-Xiang (@xiaoxiangmoe) does #35148 satisfy it? 🤔
DanielRosenwasser commentedon Mar 21, 2020
TypeScript Bot (@typescript-bot) create release-3.9
typescript-bot commentedon Mar 21, 2020
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to create the
release-3.9branch for you. Here's the link to my best guess at the log.ExE-Boss commentedon Mar 21, 2020
#37510 should probably be merged too.
It’s the only part of #36368 that wasn’t included in #35998.
DanielRosenwasser commentedon Mar 26, 2020
For those following the issue and the listed features, we noticed that a lot of code was being impacted by
awaitedand we've decided that we need to back out the feature to ensure that we can roll it out more smoothly later on. Had we caught some of the errors sooner (see #37560), we might've gotten a better hint around some more of the impact, but even then we've just hit more stuff doing offhand experiments with public repos. Since the PR, we've seenAnd we still have some fixes to
awaitedin flight:We considered keeping
awaitedin and pulling it back out if the issues seem insurmountable, but this seems like an unfair amount of churn to impose on users, especially since the fixes aren't necessarily backwards-compatible. Asking users to useawaitedand then remove it if we think it's not working out would be a waste of time for everyone.We also considered pushing back the beta another week. Adding delays for a feature isn't something we want to start doing, especially because "fixing" a feature takes an indefinite amount of time with enough unknown unknowns. In the worst-case scenario, a bunch of fixes followed by a total rollback of a feature would delay our releases even further.
So the course of action we're taking is:
awaitedtype for a later version.I think this is the most ideal outcome. By not rushing this feature, we'll have a much better handle on it and its impact. 3.9 beta won't be delayed any further, and we'll still have a reasonable amount of time for feedback before the RC for other features.
ExE-Boss commentedon Mar 26, 2020
I think that 4.0 might be a better version for
awaited, given that it has backwards compatibility issues.Jack-Works commentedon Mar 26, 2020
I think it's reasonable to request people to change the
Ttoawaited T. TypeScript is inferring it correctlyfalsandtru commentedon Mar 27, 2020
Type system shouldn't implicitly create awaited types by default. Creating awaited types by Promise functions and methods and async/await operators obviously breaks existing code. So you should provide the stricter type inference and the lib.d.ts using awaited operator only when a flag is enabled.
DanielRosenwasser commentedon Apr 24, 2020
TypeScript Bot (@typescript-bot) sync release-3.9
6 remaining items
DanielRosenwasser commentedon May 19, 2020
TypeScript Bot (@typescript-bot) bump release-3.9 and LKG
typescript-bot commentedon May 19, 2020
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to update the version number on
release-3.9to3.9.3for you. Here's the link to my best guess at the log.DanielRosenwasser commentedon May 28, 2020
TypeScript Bot (@typescript-bot) bump release-3.9 and LKG
typescript-bot commentedon May 28, 2020
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to update the version number on
release-3.9to3.9.4for you. Here's the link to my best guess at the log.DanielRosenwasser commentedon May 29, 2020
I bungled the publish and don't want to mess around with things locally.
TypeScript Bot (@typescript-bot) bump release-3.9 and LKG
typescript-bot commentedon May 29, 2020
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to update the version number on
release-3.9to3.9.5for you. Here's the link to my best guess at the log.DanielRosenwasser commentedon Jun 30, 2020
TypeScript Bot (@typescript-bot) bump release-3.9 and LKG
typescript-bot commentedon Jun 30, 2020
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to update the version number on
release-3.9to3.9.6for you. Here's the link to my best guess at the log.DanielRosenwasser commentedon Jul 15, 2020
TypeScript Bot (@typescript-bot) bump release-3.9 and LKG
typescript-bot commentedon Jul 15, 2020
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to update the version number on
release-3.9to3.9.7for you. Here's the link to my best guess at the log.DanielRosenwasser commentedon Jun 16, 2021
TypeScript Bot (@typescript-bot) bump release-3.9
DanielRosenwasser commentedon Jun 16, 2021
TypeScript Bot (@typescript-bot) bump release-3.9 and LKG
typescript-bot commentedon Jun 16, 2021
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to update the version number on
release-3.9to3.9.11for you. Here's the link to my best guess at the log.DanielRosenwasser commentedon Jun 16, 2021
Weird! Looks like it ran last time but didn't post a response. I've cancelled that run.