TypeScript 5.0 Iteration Plan

[DanielRosenwasser]

This document outlines our focused tasks for TypeScript 5.0. 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
November 15th	TypeScript 4.9 Release
January 20th	Create 5.0 Beta (5.0.1) Build for Testing
January 24th	TypeScript 5.0 Beta Release
February 24th	Create 5.0 RC (5.0.2) Build for Testing
February 28th	TypeScript 5.0 RC Release
March 10th	Create 5.0 Final (5.0.3) Build for Testing
March 14th	TypeScript 5.0 Final Release 🚀

gantt
    dateFormat  YYYY-MM-DD
    TypeScript 4.9 Stabilization Period : 2022-10-28, 2022-11-11
    TypeScript 5.0 Beta Development : 2022-10-28, 2023-01-19
    TypeScript 5.0 RC Development : 2023-01-19, 2023-02-23
    TypeScript 5.0 Stabilization Period : 2023-02-23, 2023-03-14
todayMarker stroke-width:5px,stroke:#0f0,opacity:0.5

Language and Compiler Features

• ECMAScript Decorators
• Unify All enums as Unions
• Legacy Flag Deprecation
• Investigate Bundler-Oriented Module Resolution Options
• Support .ts as a Module Specifier for Bundler/Loader Scenarios
• Declaration Files for Non-JavaScript Files
• Allow Arrays in extends for tsconfig.json Files
• Investigate Per-File Settings
• lib.d.ts Updates
• Make @types/web Versionable

Editor Productivity

• switch/case Snippet Completions
• Investigate SharedArrayBuffer-Backed Host for Web Editing Contexts
• Investigate Limited ATA-Like Scenarios in Web Editing Contexts
• Implement Cancellation in Web Editing Contexts
• Easy Run/Debug for Loose TypeScript Files

Performance

• Investigate Module Resolution Caching in .tsbuildinfo Files
• Optimizing .tsbuildinfo
• Investigate Tooling for JIT Deoptimizations

Infrastructure

• Migrate TypeScript to Modules
• Enable strictFunctionTypes on TypeScript Codebase

Website

• Make Onboarding and Cross-Platform Installation Smoother

[DanielRosenwasser]

The 4.9 iteration plan is over at #50457.

[akononenko-sumo]

It's so sad that adding proper type support for throw is not on the roadmap for v5...

[MLoughry]

One idea I had previously floated to @amcasey was to add compiler/server APIs with asynchronous signatures in 5.0 (even if they're still synchronous under the hood), and deprecate the synchronous APIs. This would allow Typescript to later (6.0?) remove the synchronous APIs and unblock the ability to perform asynchronous I/O (or even worker-based parallelization?) in future versions.

[lukeapage]

I’d love to see the core team engage with issues that are for example 400+ thumbs up and marked “awaiting feedback” rather than issues that seem less important.
Even if the answer is that the team consider it to not be typescript’s responsibility and close the issue - i would rather that than limbo and newer but less important features being tackled.

https://github.com/microsoft/TypeScript/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc+label%3A%22Awaiting+More+Feedback%22

[patroza]

@lukeapage I smell another 400+ thumbs up incoming..

[kuator]

I’d love to see the core team engage with issues that are for example 400+ thumbs up and marked “awaiting feedback” rather than issues that seem less important. Even if the answer is that the team consider it to not be typescript’s responsibility and close the issue - i would rather that than limbo and newer but less important features being tackled.

https://github.com/microsoft/TypeScript/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc+label%3A%22Awaiting+More+Feedback%22

Waiting for any news on LSP implementation

[mindlid]

Any plan to add experimental support ECMAScript Operator Overloading, Pipeline Operator or extension methods?

[ljharb]

@mindlid It would be highly inappropriate to add support for any proposal prior to stage 3.

[dilame]

Dear TS team, i really appreciate and respect your excellent work, but so much people are waiting for the throws statement, why isn't it in the 5.0 roadmap? FMPOV this functionality is directly related to the purpose of the existence of the TypeScript – typed JS. This is the feature i really miss more then any other feature – it lacks type-safety a lot.
Would be very grateful if some of team members could give a reply about it

[RyanCavanaugh]

What's that even a graph of?

[RyanCavanaugh]

Ah so it's a graph of commit count. Two people who would commit on basically every keystroke (they were good engineers, it was just their style) were active over 2015-2016 and 2017-2019, and we switched to squashing commits on merge around 2020 IIRC. Commit count is usually not the best measure of a project's, well, anything, since it entirely depends on arbitrary things like squashing and how often the people working on the project like to do intermediary commits. Of all the things that worry me about TS's future, not having enough git objects is the least of my concerns 😅

[dilame]

Of all the things that worry me about TS's future

Could you please share your thoughts about these things? Would be very interesting to read!

[SmashingQuasar]

Great to see TypeScript evolve even further, thanks for the time invested in this project!

With that being said, I am a little bit surprised as this hardly seems like a major release. Most of these changes are relatively niche and hardly breaking changes.

I understand this is not an issue to post suggestions so I won't. I just want to express that this release seems disconnected from the current TypeScript "issues". For example, having an option is tsconfig.json to force all thrown to be instances of Error and thus make error not be unknown but Error in try..catch statements seems like a much more important change than unifying Enums or catering to bundlers. Actually I am surprised than catering to bundlers is within the scope of TypeScript. It seems like something that should be it's own separate thing.

Anyway, I hope we get to see more impactful changes in 5.x versions!

[Jakob5358]

With that being said, I am a little bit surprised as this hardly seems like a major release. Most of these changes are relatively niche and hardly breaking changes.

I think typescript doesn't use semver because marketing or smth, meaning that for example 5.0 and 4.9 aren't that different, the versioning is just a way to know if you're on a newer or older version.

[SmashingQuasar]

I think typescript doesn't use semver because marketing or smth, meaning that for example 5.0 and 4.9 aren't that different, the versioning is just a way to know if you're on a newer or older version.

Can anyone confirm or infirm this please?
I'd be interested to know if TypeScript is following a specific logic regarding releases if not using SemVer.
Versioning cannot be marketing, especially for a technology aimed exclusively at IT professionals. We need version numbers to be reliable and have a clear contract on how they behave.

[rubiesonthesky]

Can anyone confirm or infirm this please?

#51392 (comment) :

Since "minor release" is often mentioned here, I'd like to add something. TypeScript does not follow semantic versioning. The version increment is always the same: Minor until 9, then major. There's no deeper meaning behind it, like "no breaking change".

Every TypeScript release should be treated as a major release, because that's what it is.

I could not find this in documentation. Maybe I did poor job searching. It would be good to have this in some central place so it would not greate more confusion. Though discussion of version practices should maybe be it's own issue (if one does not yet exists) instead in this iteration plan.

Also though all "minor" versions are "major" versions, I have seen that the team uses major for doing bigger breaking changes because that is what users expect but it's not guaranteed.

Since the version numbers and the release dates are fixed, releases will include tasks that are ready to be shipped and things that can be done for one release are limited by time.

[SmashingQuasar]

@rubiesonthesky thanks for the link!
This is going off-topic so I won't keep on going with this discussion but I appreciate the effort you put into your researches! 👍 (I also want to point out that not using SemVer and relying on x.0 => x.9 then x+1.0 => x+1.9 is absolutely terrible in my opinion)

[ssalbdivad]

Every new TypeScript version has breaking changes are listed at the end of its release notes. They also tend to affect a very small number of users and/or be correcting behavior that is obviously wrong. When they do require updates, they tend to limited in scope.

For a project like this, SemVer doesn't really add much value.

[Zain-ul-din]

@RyanCavanaugh Hey, Do you have any plan to improve OOP in typescript 5.0

[danielrentz]

The roadmap page is a bit outdated

• link list to roadmap issues ends at Jun 2021
• 4.9 features are not completed
• planned 5.0 features are missing

[abdatta]

I see some negativity in the comments, so I just want to add I'm extremely grateful to the TS team for Typescript, completely revolutionizing the experience of working with JS on large projects. Like all big projects, this too has some pitfalls and some highly requested features that are yet to make it in. I hope we reach there some day as well, but for now the 5.0 features are still very exciting! Looking forward to it ❤️ (Particularly excited about the per file settings, as it will help in enabling strict setting gradually in large repos).

[DanielRosenwasser]

@danielrentz thanks for reminding me. The feature roadmap should be up to date, link back to iteration plans across 4.8 to 5.0, and will more accurately reflect our work for 5.0 at this point than the above iteration plan.

[polkovnikov-ph]

know better or even have a concrete suggestion

As a person who has been using TypeScript since its public beta, I have quite a few things to say about the progress of the project. Mainly, I'm used to stress that ad hoc development of type systems with no regard to the last 100 years of research in type theory unsurprisingly leads to major bugs. Let's take a glimpse on what it means in this completely correct TS program:

// oops! type of JSON.stringify is broken
{
    const a = JSON.stringify(undefined);
    a.toString(); // Cannot read properties of undefined
}

// oops! type inference for overloads is broken
{
    const d = document.createElement('div');
    d.className = 'test';
    document.body.appendChild(d);
    const r: null | HTMLScriptElement = document.querySelector('.test');
    r?.src.toString(); // Cannot read properties of undefined
}

// oops! type system doesn't handle non-enumerable properties
{
    const rect1 = document.body.getBoundingClientRect();
    const rect2 = {...rect1};
    console.log(rect2.x.toString()); // Cannot read properties of undefined
}

// oops! not even properties from prototypes
{
    const a = new Map();
    const b = {...a};
    b.get(1); // b.get is not a function
}

// oops! narrowing is broken
{
    const m: { [key: string]: string } = {};
    const i = '123';
    const j: string | null = m[i];
    j.toString(); // Cannot read properties of undefined
}

// oops! narrowing is broken again
{
    type A =
        | {a: 0, b: undefined}
        | {a: 1, b: string}
    ((x: A) => {
        x.a = 1;
        if (x.a) {
            x.b.toString(); // Cannot read properties of undefined
        }
    })({a: 0, b: undefined});
}

// oops! and again narrowing is broken
{
    ((x?: string) => {
        if (typeof x === 'string') {
            const fn = () => x = undefined;
            fn();
            console.log(x.toString()); // Cannot read properties of undefined 
        }
    })('a');
}

// oops! what is this again? broken narrowing?
{
    let cnt = 0;
    const x = {
        get a(): number | null {
            if (cnt === 0) {
                cnt = 1;
                return 1;
            } else {
                return null;
            }
        }
    };
    if (x.a) {
        x.a.toString();
    }
}

// oops! enums are broken
{
    enum A { B }
    ((x: A) => [0][x].toString())(10); // Cannot read properties of undefined
}

// oops! method calls are broken
{
    class A {
        private a = 'a';
        b() { return this.a.toString(); }
    }
    const {b} = new A();
    b(); // Cannot read properties of undefined
}

// oops! subtyping is broken
{
    type A = { a(): string };
    type B = { b(): string };
    const f = (x: A | B) => "a" in x ? x.a() : x.b();
    const x = { a: 10, b() { return "hello"; } };
    const y: B = x;
    f(y); // x.a is not a function
}

// oops! subtyping is broken again
{
    const a = (b: { c(d: {}): void }) => b.c({e: 1});
    a({ c: (d: { f: 1 }) => d.f.toString() }); // Cannot read properties of undefined
}

// oops! type system doesn't even handle TDZ
{
    const f = () => x;
    f(); // Cannot access 'x' before initialization 
    const x = 0;
}

The top-level suggestion is, of course, to start fixing major bugs in type system, like

• do binding group analysis properly;
• make a distinction between open and closed object types (and type the in operator in a way that narrows on either of its arguments);
• handle union and intersection types symmetrically (for example, fix the intentional bug that handles the last overload);
• at least try to create some introduction and elimination syntax forms for the types that don't have any (such as mapped object types);
• decide on whether recursive types use specialization, or if they are proper mu-types, and handle them consistently.

A good starting point would be to

• open EcmaScript standard, find mentions of *Error, and write tests that fail in that way
• write a fuzzer that finds cases when code doesn't use any unsafe features (as, any, type guards, overloads etc.) and TS doesn't find any bugs, but it fails in runtime, and add those to a set of tests too
• use number of failing tests as KPI of TS team
• make developers fix bugs instead of adding new features

Even though TS provides a 3x improvement in development time over pure JS in large projects, it still takes a witch doctor who knows major compiler bugs and directs other developers to avoid them, and the majority of development time is spent on that instead of actually implementing business logic. Sadly, by the rate and the way the bugs get fixed right now, it would take approximately 100 years to fix bugs that are already present.

Worse, development of some libraries that handle JSON serialization (such as zod), state management (redux) and rendering (react) is significantly impeded by lack of higher-kinded types and effects (or at least typed throws). At the moment there is no way to properly type useContext (because no effects) or a generic store/API schema (because no HKTs). Given that TS became a standard for web development, we end up with large amount of boilerplate or unsafe code in every of those cases with no way out for our codebases.

[RyanCavanaugh]

make developers fix bugs instead of adding new features

Things you don't like about software aren't bugs. 100% soundness has been a documented non-goal of the project for 7+ years. Pretty much everything you listed there is either entirely by-design (if these are your goals for a language, literally please do use PureScript or Hegel instead), is already implemented (you forgot to turn on noUncheckedIndexedAccess!), or is a tracked feature request to seal up a known unsoundness.

[polkovnikov-ph]

Sorry, but this is some kind of misdirection. "Soundness" is merely a polite way to say "lack of bugs" in academia. If the nongoal is expressed in plain language (such as "we don't intend to write a compiler that works"), it makes much less sense. Even if there is trade-off between handling all the bugs and type system complexity, and it's explicitly specified, the language is still said to be sound (for example, Haskell's type system is sound if you don't do things such as unsafePerformIO). Bugs are still bugs, even if you politely call them "unsoundness" and confuse developers by mixing them up with trade-offs.

Unfortunately, TS doesn't have any specification, not even informal, yet alone specification of its trade-offs, and is genuinely unsound, i.e. has bugs in basic functionality such as array methods, JSON methods, objects and function calls. The specified examples are just a minified form of the problems people encountered in production. If that's "by design", please, reconsider what a design is.

Also, TS playground has strict mode enabled, so it's likely that you forgot to enable noUncheckedIndexedAccess.

[evelant]

It strikes me that since TS has become so ubiquitous and gained so many advanced features there are seemingly two distinct categories of users.

On one hand there are people who want typescript per its original design goals, primarily js with erasable types for incremental adoption.

On the other hand there are people for whom plain js is more or less a compile target, they never write it directly. I think it's this class of users who sometimes are critical of TS because it's close to their use case of an advanced strictly typed language that compiles to optimized js but they forget (or don't know) that's outside the design goals of TS.

I think there's probably room for another language in the ecosystem. A sibling of TS with type directed output, nominal types, soundness, and other advanced features outside of the original TS design goals. That is IMO what a lot of TS detractors want TS to be, hence the frustration. IDK if such a thing could live under the TS umbrella or if it needs to come to life as its own language.

Perhaps some extra documentation or prominent featuring of the TS design goals could help people realize that TS isn't intended to be exactly what they're looking for. Might reduce the amount of frustrated comments like the above.

[RyanCavanaugh]

People wishing to rehash old discussions can pick up at #9825 (comment) to see where this is going to go; let's keep further discussion here on-topic.

[Zain-ul-din]

Hey, Typescript team please can you fix this also in 5.0 version

[Thundercraft5]

Could #52035 be investigated? It's a small but important and far-reaching bug for HKT and FP users, if fixed it will allow some basic HKT in TS for the first time.

[DanielRosenwasser]

We're going to try to get the beta out tomorrow. We've had to do some manual testing, and documenting's taken a bit longer.