TypeScript 5.1 Iteration Plan

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

Compiler

Language Service

Performance

Infrastructure

Website

The previous Iteration Plan for TypeScript 5.0 is available here.

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);
}

Please fix this #9619 issue existing from 2016

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.

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.

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.

Ryan Cavanaugh (@RyanCavanaugh)

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!?

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.

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

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

Did someone say bread 👀

Maru Alka (@minecrawler)

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.

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.

fix(deps): update dependency typescript to v5.6.2

fix(deps): update dependency typescript to v5.6.3

Navigation Menu

Repository navigation

TypeScript 5.1 Iteration Plan #53031

Compiler

Language Service

Performance

Infrastructure

Website

78 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

TypeScript 5.1 Iteration Plan #53031

Description

Compiler

Language Service

Performance

Infrastructure

Website

Activity

DanielRosenwasser commented on Mar 1, 2023

minecrawler commented on Mar 1, 2023

alpharder commented on Mar 1, 2023

RyanCavanaugh commented on Mar 1, 2023

alpharder commented on Mar 1, 2023

RyanCavanaugh commented on Mar 1, 2023

minecrawler commented on Mar 2, 2023

DaSchTour commented on Mar 2, 2023

k4b7 commented on Mar 2, 2023

fatcerberus commented on Mar 2, 2023

olivermrose commented on Mar 2, 2023

reverofevil commented on Mar 3, 2023

reverofevil commented on Mar 3, 2023

78 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions