TypeScript 5.0 Iteration Plan

DanielRosenwasser commented 2 years ago

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.0) Build for Testing
January 24th	TypeScript 5.0 Beta Release
February 24th	Create 5.0 RC (5.0.1) Build for Testing
February 28th	TypeScript 5.0 RC Release
March 10th	Create 5.0 Final (5.0.2) Build for Testing
March 16th	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-24
    TypeScript 5.0 Stabilization Period : 2023-02-24, 2023-03-16
todayMarker stroke-width:5px,stroke:#0f0,opacity:0.5

Language and Compiler Features

Editor Productivity

Performance

Infrastructure

Website

Make Onboarding and Cross-Platform Installation Smoother

DanielRosenwasser commented 2 years ago

The 4.9 iteration plan is over at https://github.com/microsoft/TypeScript/issues/50457.

akononenko-sumo commented 2 years ago

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

MLoughry commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

kuator commented 1 year ago

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

elsaulio commented 1 year ago

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

ljharb commented 1 year ago

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

elsaulio commented 1 year ago

@ljharb any feature can be added despite being a proposal or not, that's the point of being a superset of javascript

ljharb commented 1 year ago

@mindlid can be, sure. but a) it's not a superset in any way, and b) proposals aren't in JavaScript until they're stage 4, so your argument doesn't hold up anyways.

elsaulio commented 1 year ago

a) it's not a superset in any way

hmm... aren't features like string literate templates or enums not superset features???? Any feature in TS which is not in JS falls into the SuperSet, including the type system, it's basic set logic.

b) proposals aren't in JavaScript until they're stage 4

okay, don't be confused, who is talking about JS?, Typescript is not limited to the features of Javascript, JS it's only a subset of the TS superset. According to your logic, you may want to remove the type system from Typescript until Proposal Type Annotations gets into Javascript

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

Features like Decorators have been in experimental support before Stage 3, that why you run them with --experimental<featureName>, and that's why the --experimental<featureName> parameters exist

TS is not just JS with types, is it's own set of unique features plus the ones of JS

@ljharb

ljharb commented 1 year ago

@mindlid yes, and TS's inclusion-by-default of a five-times-obsolete form of decorators is one of the larger mistakes it's made, as I believe they've acknowledged. I'm well aware TS is not just JS with types - that's why it's not a superset.

The issue is that pre-stage-3 features are subject to change a lot, especially the ones you mentioned - the possible churn isn't worth it.

elsaulio commented 1 year ago

you cannot call a mistake to change a experimental feature, that's the point of being marked as experimental, users can test, give feedback, improve the design, typescript is used as guinea pig for some future ECMAScript features, so thanks Typescript for your "failures", so the final ECMAScript feature will learn from your errors.

On the other hand if you use an experimental feature treating it as stable, and complaining about breaking changes, that's not a Typescript mistake, but a clear misunderstanding of the purpose.

@ljharb

ljharb commented 1 year ago

@mindlid I'm going to stop arguing about this here since the TS team has stated their policy on this in the past, and it's not worth discussing unless they change it :-) TC39 has lots of ways to get feedback on syntax features prior to stage 3, and "ship them in TS" needn't be one of them.

TS team, I urge you to hide these comments since they will likely be distracting to those attempting to read the issue.

dilame commented 1 year ago

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 commented 1 year ago

I think we'll probably take a post-5.0 activity of "Saying 'no' to a bunch of things that aren't going to happen in the next five years" (I can't wait for the flood of 👎s that's going to get me 😀).

I would request that people not use the 5.0 iteration plan any further for pointing out that our suggestion backlog exists.

eekelof commented 1 year ago

Allowing .ts extension would enable code sharing with a Deno backend. +1 for "Support .ts as a Module Specifier for Bundler/Loader Scenarios".

RobertAKARobin commented 1 year ago

+1 for the .ts extension. This would be huge.

reverofevil commented 1 year ago

"Saying 'no' to a bunch of things that aren't going to happen in the next five years"

👍 for audacity to think TypeScript will survive 5 years with such neglect to community opinion and codebase quality. That's the spirit.

RyanCavanaugh commented 1 year ago

What's that even a graph of?

RyanCavanaugh commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Can anyone confirm or infirm this please?

https://github.com/microsoft/TypeScript/issues/51392#issuecomment-1301968974 :

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

danielrentz commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

reverofevil commented 1 year ago

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 commented 1 year ago

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.

reverofevil commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

People wishing to rehash old discussions can pick up at https://github.com/microsoft/TypeScript/issues/9825#issuecomment-350998372 to see where this is going to go; let's keep further discussion here on-topic.

Zain-ul-din commented 1 year ago

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

Thundercraft5 commented 1 year ago

Could microsoft/TypeScript#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 commented 1 year ago

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.

Jack-Works commented 1 year ago

@storybook+react-docgen-typescript-plugin@1.0.2-canary.6.9d540b91e815f8fc2f8829189deb00553559ff63.0 breaks with TS 5.0-beta.

TypeError: typescript_1.default.createIdentifier is not a function

I know ts.createIdentifier is deprecated (ts.factory.create* instead). Are those deprecated methods totally removed in TS 5.0?

jakebailey commented 1 year ago

Yes, see microsoft/TypeScript#52314. They have been deprecated for the past 2+ years (since 4.0).

Jack-Works commented 1 year ago

Thanks, I'll open an issue in that library. But this breaking change is not documented in https://github.com/microsoft/TypeScript/wiki/API-Breaking-Changes

jakebailey commented 1 year ago

Thanks, I'll open an issue in that library. But this breaking change is not documented in microsoft/TypeScript/wiki/API-Breaking-Changes

I'll document it there, though I'm pretty sure that use of these functions should have been logging deprecation warnings since TS 4.1.

AliMD commented 1 year ago

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

This is not version 5! its just version 4.10 or better say version 3.20! Microsoft does not understand semantic versioning and always make jump major-version after x.9. Because Microsoft developers do not have a proper understanding of x.10 > x.9 and this is confusing for them. If TypeScript wasn't open source, it would be version 2023 now!

Jack-Works commented 1 year ago

If TypeScript wasn't open source, it would be version 2023 now!

Some OOT just want to notify you that some other open source languages are also versioned by year like ECMAScript 2022 or rust edition 2022 (well that's not a "version" strictly)

gund commented 1 year ago

This is not version 5! its just version 4.10 or better say version 3.20!

There have been many breaking changes between v3 and v4 even between minors, so if anything it should've been version 6+ (probably 10ish) 😁

Also it's important what TS considers it's "public API" - if it's only usage of the compiler then it's one thing but if it also includes API to work with AST then there were even more breaking changes and the version should've been even higher by now (20+?).

Either way in the current state TS versioning is hardly following a SemVer and you should just treat it as "edition" which does not tell you anything about it's BC guarantees and your best friend is their release notes.

RyanCavanaugh commented 1 year ago

This is not version 5! its just version 4.10 or better say version 3.20

There is literally a long list of breaking changes which we specifically put in this release.

People can have a lot of semver complaints but "5.0 was incorrectly a major bump" is not one of them.

nstepien commented 1 year ago

Would it be too late to add "change array by copy" [0] methods types in TS 5.0? They shipped in Chrome 110 stable, and have reached stage 4 [1]. [0] https://github.com/tc39/proposal-change-array-by-copy [1] https://github.com/tc39/proposals/commit/ad4df8435f27f39eda26db3b940ae151980c8015

(I now see there already is an issue open about it #50333)

SmashingQuasar commented 1 year ago

This is not version 5! its just version 4.10 or better say version 3.20

There is literally a long list of breaking changes which we specifically put in this release.

People can have a lot of semver complaints but "5.0 was incorrectly a major bump" is not one of them.

I don't want to start a debate about it, just want to point out that deprecations do not fall under the breaking change status because they don't break anything yet. Removal of syntax or features is what falls under the breaking changes nomenclature.

Overall, I think the question is not really "Have you introduced breaking changes in 5.0?" but more of "Shouldn't you use a real Semantic Versioning instead of doing x.1 => x.9 on every pseudo-major?".

It can be difficult to understand someone's tone over text so I want to emphasize that there is no disdain, irony or sarcasm in what I just wrote. I believe this is a legitimate question and we had some eyebrows being raised in my company, especially from our CTO that questioned why this is being done that way.

microsoft / TypeScript