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]

@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.

[kevinbarabash]

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

[xiBread]

Did someone say bread 👀

[reverofevil]

@minecrawler

@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.

[reverofevil]

how long an issue has been open is not really an input to the prioritization process

I should mention that C++ is developed by a committee, and the choice of features to be or not to be developed is done in the open. While there are Iteration Plans regularly posted here and even logs of Design Meetings, reasons behind feature discussion and implementation are completely opaque.

For example, JSX factories ticket was not only discussed previously, but also implemented. Then it was closed after 3 years without any review because it was "old". So in which situations age matters and in which it doesn't? Were JSX factories important in 2019, became unimportant afterwards, and then suddenly became important again in 2023? Well, we don't know anything about it.

[minecrawler]

@polkovnikov-ph

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.

I'm not sure that would be a problem. At least not for now, since the request is just about implementing support, not about adding typing. Adding typing may or may not be a later step, which may even be handled by the community entirely. But it needs support first.

Also, if the TS Team at MS has strong arguments against typed throws, then instead of keeping the issue open it's time to close it with the reason as a final comment. The current state and workflow is just very frustrating; and every question for how I or others from the community can help is met with silence or unrelated comments. Which, again, adds to the frustration.

In a nutshell, since I care about having properly typed interfaces (error propagation is an interface), I want this feature and I wonder if support may be included in this iteration, or if there is a blocker or roadmap for later on.

[reverofevil]

Imagine you have

const f = (): void throws never => {
    [1, 2, 3].forEach(i => {
        if (i === 2) {
            throw 42;
        }
    })
};

In order for the check to work, you have to specify that forEach doesn't consume any of those errors inside of it. The type would have to be roughly

interface Array<T> {
    forEach<U>(callback: (value: T, index: number) => void throws U): void throws U;
}

and the "support" would at least need to have these annotations in all standard libraries, not to mention massive overhead of specifying these types. Worse, this feature is viral, so if you have a library that exposed checked exceptions in its API, all the code written with that library would have to implement checked exceptions too.

Worse, the catch part is sketchy too. Unlike Java, JS doesn't check runtime type of the exception. catch (e: T) only can specify the full type of exception. Not only these types will easily become unwieldy by listing all the possible exception in a union, but would also break with updates of third-party libraries, and would have to always list things such as stack overflow exception that can happen literally at any function call.

Also the interview mentioned a few other points on why this might not be a good idea:

• similar features were implemented in C++ and Java, and in neither case it ended up with more stable code;
• the catch { /* do nothing*/ } people are everywhere.

While I would definitely want to see this feature in TS (indeed, it can even be abused to type React's useContext), it would likely bring several-year long disrepair to the whole ecosystem.

met with silence

The silence itself is not a problem, it usually means people are working. In fact, newly opened tickets get triaged in only a day, which means developers are actually engaged with this bug tracker. The problem is that we have no idea where in backlog those tickets are, and even if there is any backlog at all.

[minecrawler]

I think for this iteration, our discussion is off topic, so maybe it would be better to bring it back to the original issue! (see my answer over there)

[oles]

Grats on the 5.0 release! Great to see better ESM support and finally --allowImportingTsExtensions ❤️

If this is the place to come with suggestions - my team and I would really like to see #32063 implemented, as we're using JSON Schema - and are currently working around that issue by defining them in TypeScript files ✌️

[AliMD]

Hoping for a day when there will be no more news about JSX/TSX

[DanielRosenwasser]

As a heads up, we are pushing out each release out by about a week or so. That means expect:

• the beta on April 18
• the RC on May 18
• the Stable release on May 30

[xiBread]

With Async ERM having reached stage 3, is the plan to implement it in this release with normal ERM or later as initially planned?

[DanielRosenwasser]

While we're championing the explicit resource management proposal, the implementation work did not make it in time for TypeScript 5.1, so we'll likely have it for TypeScript 5.2.

[DanielRosenwasser]

Oh and also - TypeScript 5.1 Beta is out everyone!

[WORMSS]

@DanielRosenwasser the "iteration plan" on your 5.1 Beta document doesn't point to THIS iteration plan, but the iteration plan for 4.8