TypeScript 3.9 Iteration Plan

[DanielRosenwasser]

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.

Date	Event
February 20th	TypeScript 3.8 Release (past)
March 20th	Create 3.9 Beta (3.9.0) Build for Testing
March 24th	TypeScript 3.9 Beta Release
April 24th	Create 3.9 RC (3.9.1) Build for Testing
April 28th	TypeScript 3.9 RC Release
May 8th	Create 3.9 Final (3.9.2) Build for Testing
May 12th	TypeScript 3.9 Final Release 🚀

Work Items

Expected Work Items

• Stability
  • Eliminate crashes
    • Address compiler-bound crashes first, typically impact the LS too.
    • Assign priorities to crashes from telemetry and fuzzing
    • Compiler team addresses work items
  • Investigate better TSServer logging for easier issue reports
• Performance
  • Investigative
    • Work with users
  • Improve build times for popular libraries
    • Giant unions (MUI and styled-components)
  • Update Perf Suite
    • Current Compiler
    • Code using popular libraries
  • Parallelized --build mode for project references
  • Lazy-loading projects in preview tabs
• Infrastructure
  • Moving to modules
    • Helps us catch module issues sooner
    • Eventually can be the basis of solving package size issues
  • Pull Request Debt
  • Automate more release activities
• Compiler work
  • The awaited type
  • Live bindings for getters
  • lib.d.ts Updates
  • Bug Squashing!
• Editor Productivity and Language Service
  • VS Code Priority bugs
  • Investigate Discoverability for Refactorings/Quick Fixes
  • Switch ATA to GitHub Package Registry
    • Tentative: blocked on un-authenticated downloads
• Command Line Tooling
  • downlevel-dts
    • Move to Microsoft organization
    • Set out policies/contribution guidelines
    • Provide documentation and workflow guidance
• Documentation
  • Handbook
  • Website
  • Clarify Contributing Guidelines

[LittleStoney]

Thanks

[ExE-Boss]

The current awaited type operator PR is #35998.

[masx200]

#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]

Is it possible to support mjs/cjs in ts 3.10?

[Jack-Works]

@xiaoxiangmoe does #35148 satisfy it? 🤔

[DanielRosenwasser]

@typescript-bot create release-3.9

[typescript-bot]

Heya @DanielRosenwasser, I've started to create the release-3.9 branch for you. Here's the link to my best guess at the log.

[ExE-Boss]

#37510 should probably be merged too.

It’s the only part of #36368 that wasn’t included in #35998.

[DanielRosenwasser]

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

• Regression: Argument of type 'awaited T' is not assignable to parameter of type 'T' #37534
• VS Code codebase compile errors with 3.9.0-dev.20200324 #37556
• New error: Type 'awaited T' is not assignable to type 'T'. #37564
• New error: Argument of type '(result: Result) => void' is not assignable to parameter of type '(value: awaited Result) => void | PromiseLike<void>' #37566
• New error: Argument of type 'awaited T' is not assignable to parameter of type 'T'. #37567
• New error: type not assignable #37572

And we still have some fixes to awaited in flight:

• Fix inference of type arguments when source is 'awaited' #37540
• Weaken the definition of PromiseLike to allow 'T | awaited T' #37570

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:

1. Delay the beta by another day or two.
2. 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).
3. 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.

[ExE-Boss]

I think that 4.0 might be a better version for awaited, given that it has backwards compatibility issues.

[Jack-Works]

I think it's reasonable to request people to change the T to awaited T. TypeScript is inferring it correctly

[falsandtru]

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.

// strictAwaitedTypes: false
// lib.es5.d.ts
  then((value: T) => awaited T | T): Promise<T>;
// strictAwaitedTypes: true
// lib.es5.awaited.d.ts
  then((value: awaited T) =>  awaited T | T): Promise<awaited T>;

// strictAwaitedTypes: false
await value; // Returns T
// strictAwaitedTypes: true
await value; // Returns awaited T