Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeScript 5.0 Iteration Plan #51362

Open
DanielRosenwasser opened this issue Oct 31, 2022 · 48 comments
Open

TypeScript 5.0 Iteration Plan #51362

DanielRosenwasser opened this issue Oct 31, 2022 · 48 comments
Labels
Planning Iteration plans and roadmapping

Comments

@DanielRosenwasser
Copy link
Member

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

Editor Productivity

Performance

Infrastructure

Website

@DanielRosenwasser DanielRosenwasser added the Planning Iteration plans and roadmapping label Oct 31, 2022
@DanielRosenwasser DanielRosenwasser pinned this issue Nov 1, 2022
@DanielRosenwasser
Copy link
Member Author

The 4.9 iteration plan is over at #50457.

@akononenko-sumo
Copy link

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

@MLoughry
Copy link

MLoughry commented Nov 2, 2022

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
Copy link

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
Copy link

patroza commented Nov 11, 2022

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

@kuator
Copy link

kuator commented Nov 27, 2022

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
Copy link

mindlid commented Dec 4, 2022

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

@ljharb
Copy link
Contributor

ljharb commented Dec 4, 2022

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

@mindlid

This comment was marked as off-topic.

@ljharb

This comment was marked as off-topic.

@mindlid

This comment was marked as off-topic.

@ljharb

This comment was marked as off-topic.

@mindlid

This comment was marked as off-topic.

@ljharb

This comment was marked as off-topic.

@dilame
Copy link

dilame commented Dec 8, 2022

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

@ssalbdivad
Copy link

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
Copy link

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

@danielrentz
Copy link

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
Copy link

abdatta commented Jan 10, 2023

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
Copy link
Member Author

@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
Copy link

polkovnikov-ph commented Jan 11, 2023

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
Copy link
Member

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
Copy link

polkovnikov-ph commented Jan 11, 2023

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
Copy link

evelant commented Jan 12, 2023

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
Copy link
Member

RyanCavanaugh commented Jan 12, 2023

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
Copy link

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

@Thundercraft5
Copy link

Thundercraft5 commented Jan 19, 2023

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
Copy link
Member Author

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
Copy link
Contributor

@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
Copy link
Member

jakebailey commented Jan 30, 2023

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

@Jack-Works
Copy link
Contributor

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
Copy link
Member

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
Copy link

AliMD commented Feb 3, 2023

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
Copy link
Contributor

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
Copy link

gund commented Feb 3, 2023

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Planning Iteration plans and roadmapping
Projects
None yet
Development

No branches or pull requests