TypeScript 5.0 Iteration Plan #51362
Comments
|
The 4.9 iteration plan is over at #50457. |
|
It's so sad that adding proper type support for |
|
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. |
|
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. |
|
@lukeapage I smell another 400+ thumbs up incoming.. |
Waiting for any news on LSP implementation |
|
Any plan to add experimental support ECMAScript Operator Overloading, Pipeline Operator or extension methods? |
|
@mindlid It would be highly inappropriate to add support for any proposal prior to stage 3. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Dear TS team, i really appreciate and respect your excellent work, but so much people are waiting for the |
|
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. |
|
@RyanCavanaugh Hey, Do you have any plan to improve |
|
The roadmap page is a bit outdated
|
|
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 |
|
@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. |
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
A good starting point would be to
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 |
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 |
|
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 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 |
|
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. |
|
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. |
|
Hey, Typescript team please can you fix this also in 5.0 version |
|
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. |
|
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. |
|
@storybook+react-docgen-typescript-plugin@1.0.2-canary.6.9d540b91e815f8fc2f8829189deb00553559ff63.0 breaks with TS 5.0-beta.
I know |
|
Yes, see #52314. They have been deprecated for the past 2+ years (since 4.0). |
|
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 |
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. |
This is not version |
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) |
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. |
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. |
and others
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.
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.5Language and Compiler Features
enums as Unions.tsas a Module Specifier for Bundler/Loader Scenariosextendsfortsconfig.jsonFileslib.d.tsUpdates@types/webVersionableEditor Productivity
switch/caseSnippet CompletionsSharedArrayBuffer-Backed Host for Web Editing ContextsPerformance
.tsbuildinfoFiles.tsbuildinfoInfrastructure
strictFunctionTypeson TypeScript CodebaseWebsite
The text was updated successfully, but these errors were encountered: