TypeScript 5.1 Iteration Plan

[DanielRosenwasser]

This document outlines our focused tasks for TypeScript 5.1. It minimally indicates intent to investigate tasks or contribute to an implementation. Nothing is set in stone, but we will strive to complete these tasks in a reasonable timeframe.

Date	Event
March 16th	TypeScript 5.0 Release
April 14th	Create 5.1 Beta (5.1.0) Build for Testing
April 18th	TypeScript 5.1 Beta Release
May 12th	Create 5.1 RC (5.1.1) Build for Testing
May 18th	TypeScript 5.1 RC Release
May 26th	Create 5.1 Final (5.1.2) Build for Testing
May 30th	TypeScript 5.1 Final Release 🚀

gantt
 dateFormat YYYY-MM-DD
 TypeScript 5.0 Stabilization Period : 2023-02-24, 2023-03-10
 TypeScript 5.1 Beta Development : 2023-02-27, 2023-04-14
 TypeScript 5.1 RC Development : 2023-04-14, 2023-05-12
 TypeScript 5.1 Stabilization Period : 2023-05-12, 2023-05-26
todayMarker stroke-width:5px,stroke:#0f0,opacity:0.5

Loading

Compiler

• using Declarations
• Investigate Improved Inference and Checking Between Overloads
• Investigate Consulting JSX Factories
• Improved typeRoots Behaviors
• Investigate Custom File-Watching
• lib.d.ts Updates

Language Service

• Move to Existing File
• Mirror Cursor for JSX
• @param Snippet Completions
• Auto-Separating Object Literal Completions
• Support Go to Source Definition UX Improvements
• Organize Type Imports
• Automatic Type Acquisition in Web Contexts
• Address Crawler-Detected Crashes

Performance

• Expand Performance Suite
• Optimize JSDoc Parsing
• Reduce Path Probing During Resolution
• Investigate Caching Resolutions in .tsbuildinfo
• Tooling for Inline Cache and Hidden Class Analysis

Infrastructure

• Move to npm for Bootstrapping
• Use Same Types Between Compiler and API/Language Service

Website

• Site Simplifications
• Make Onboarding and Cross-Platform Installation Smoother
• Investigate Reducing Build Time
• Author and Iterate on Module Documentation

[DanielRosenwasser]

The previous Iteration Plan for TypeScript 5.0 is available here.

[minecrawler]

How possible is it to investigate #13219 for release 5.1? This feature with 1200+ likes has been open since 2016.

While I understand that a full implementation of all throws clauses in all interfaces is breaking too much and may be a lot of manual work, just implementing support for this proposal for library authors and application developers may be enough. Once it sees adoption, adding support for core JS calls in a later release will be a lot smoother and could until then even be done using third-party or opt-in type declarations hosted on NPM.

/**
 * @description
 * Example function for demonstrating typed throws.
 * The function throws for values > 0.5
 * @param seed Optional static number 0..1 to use for throw demonstration
 * @return Seed used for evaluation
 * @throws String with a user-readable error message
 */
function foo(seed?: number): number throws string {
 const num = seed ?? Math.random();
 if (num > 0.5) {
 throw `Threshold: ${num.toString()}!`;
 } else {
 return num;
 }
}

// Example without throws-declaration:
try {
 const result = await fetch('https://github.com');
 //...
} catch(e: unknown) {
 if (!(e instanceof TypeError)) return;
 // e is now of type TypeError

 console.error(e.message);
}

// Example with throws-declaration:
try {
 console.log(foo());
} catch(e: string) {
 console.error(e);
}

// Example with throws-declaration, but not compiling:
try {
 console.log(foo());
} catch(e: TypeError) {// Error: Type "TypeError" is never thrown in try-block. Possible types include "string" or "unknown"!
 console.error(e);
}

[alpharder]

Please fix this #9619 issue existing from 2016

[RyanCavanaugh]

FYI, how long an issue has been open is not really an input to the prioritization process. Otherwise C++ would have a garbage collector, since people have been asking for it since 1986.

[alpharder]

FYI, how long an issue has been open is not really an input to the prioritization process. Otherwise C++ would have a garbage collector, since people have been asking for it since 1986.

I understand and agree with your point, but it’s too generic and unrelated to what I asked for. With all respect, asking C++ to become GC’ed is incomparable to asking TS built-in types to support ECMAScript spec.

[RyanCavanaugh]

My point is just that, within a few years of using a programming language, one can conceive of probably 90% of the possible features you could ever add to that language. The fact that the vast majority of as-yet-unadded features date to ca.2016 is an unremarkable facet in light of TS being somewhat widely used starting in 2013.

[minecrawler]

Ryan Cavanaugh (@RyanCavanaugh)

FYI, how long an issue has been open is not really an input to the prioritization process. Otherwise C++ would have a garbage collector, since people have been asking for it since 1986.

Yes, but it's not about the age and what's in line, but about if the amount of input is enough to warrant further inspection and maybe even inclusion. Your mentioning of C++ GCs doesn't answer my question! Can we pls stay on topic: What's next for TS, is typing for throws a candidate? If not, what's missing and what steps can we take to make progress!?

[DaSchTour]

There are also issues that are even older and have a lot of duplicates and are still not solved. I would love to see #299 fixed. It's even a three digit number.

But actually I doubt that it will ever be fixed.

[k4b7]

Is there any chance that #19139 could be considered for inclusion in 5.1 or maybe 5.2? 🙏

[fatcerberus]

TypeScript 5.1. 5 + 1 = 6. 6 is half of 12. There are 12 eggs in a dozen. TS 5.1 beta is coming out 2 days after easter. 12 + 2 = 14, but the Easter bunny will steal 1 egg so therefore there will be 13 eggs. A baker's dozen. But also 13 is an unlucky number. So TS 5.1 will be very unlucky for bakers and therefore should implement typing for all bread-related code to prevent bakers from losing their jobs

...okay, that's enough of that

[olivermrose]

Did someone say bread 👀

[reverofevil]

Maru Alka (@minecrawler)

Anders Hejlsberg (@ahejlsberg) gave a very clear reasoning of why throws is not going to become a part of the language: because in order for those to work, you have to specify how higher-order functions handle throws from their functional arguments, and he doesn't think adding these annotations to every .d.ts on DefinitelyTyped is viable.

If anyone also remembers the interview and still has a link at hand, please, share.