TypeScript 4.0 Iteration Plan

DanielRosenwasser commented 4 years ago

This document outlines our focused tasks for TypeScript 4.0, as well as some of the discussion that explains how/why we prioritized certain work items. Nothing is set in stone, but we will strive to complete them in a reasonable timeframe.

Date	Event
May 12th	TypeScript 3.9 Release (past)
June 22nd	Create 4.0 Beta (4.0.0) Build for Testing
June 25th	TypeScript 4.0 Beta Release
July 31st	Create 4.0 RC (4.0.1) Build for Testing
August 6th	TypeScript 4.0 RC Release
August 14th	Create 4.0 Final (4.0.2) Build for Testing
August 20th	TypeScript 4.0 Final Release 🚀

Language Features

Editor Productivity

Performance

More Type-Checking Optimizations
Investigate Bottlenecks in Larger Apps

Infrastructure

Migrate TypeScript to Modules
Expand Commands Tested in TSServer Crawler
GitHub Crawler Infrastructure to Find Breaking Changes

Investigate High-Demand Bug Fixes

checkmatez commented 4 years ago

Would you consider to include https://github.com/microsoft/TypeScript/pull/29818 in 4.0 maybe behind experimental flag?

Jessidhia commented 4 years ago

That gets complicated by the change in factory function definition in itself.

It could be interesting to introduce a separate factory virtual type definition, though; say, JSX.Factory, or React.JSX.Factory, which TypeScript could then use for inference. I'm not quite sure just translating JSX grammar to function calls is sufficient or efficient but, since it's a virtual type, it doesn't have to correspond to any concrete JavaScript entity. The risk, of course, is getting into the same situation as we have now, with a bunch of virtual types that ended up limiting the type safety, not only of children, but of several features introduced after React 15.

ExE-Boss commented 4 years ago

Would you consider to also include https://github.com/microsoft/TypeScript/pull/24738 in 4.0 as well?

leemhenson commented 4 years ago

I'm a bit sad to see no mention of #33038 [👍 140 and an actual PR by your own @weswigham] or #202 [👍 390] while tickets like #15230 [👍 27] are considered "high-demand". I realise you can't really compare or prioritise on the basis of "likes" but it would be great if there was some roadmap update on these, especially as 4.0 seems like nice opportunity to introduce a feature like this. 🙏

Skillz4Killz commented 4 years ago

~3.5-year-old issue awaiting feedback with almost 200 comments #13778 with inaccurate typings provided for stuff like array destructuring. Pwetty pwease can we implement fix 🙏

DanielRosenwasser commented 4 years ago

I appreciate people occasionally boosting issues that they believe need attention on the roadmaps and iteration plans, but I think I need to be clear here -that "investigate high demand bug fixes" section was determined by looking through issues that were clearly causing a lot of papercuts but which seemed reasonable in scope. We're definitely still mindful of the issues mentioned, but some of them are not as scoped nor do they have a clear ideal outcome.

Examples:

Nominal brands would be nice, but would that compose with future language direction around nominality? I even have this concern with placeholder types as the person who proposed it.
undefined on index signatures is an example of something that's interesting, but we don't want to add behavior that makes it harder for 90% of people who already operate under the current assumptions. Finding an approach that composes and allows users to incrementally adopt those checks isn't something that's obvious to us. Even if it's technically possible with a bunch of conditional types and special compiler checks, those solutions tend to be very clearly hacky and break down fast.

aminpaks commented 4 years ago

Nominal brands would be nice, but would that compose with future language direction around nominality?

@DanielRosenwasser what is the future language direction in your vision?

DanielRosenwasser commented 4 years ago

I guess I'll give some context on where my mind is with nominality. There are a lot of different ideas people have in mind when they ask about nominal types, including

"Traditional" declaration-based nominality (e.g. what you see in most OO languages)
Opaque types (types whose contents are entirely unknown outside)
Distinct aliases (single-member structs in C/C++/C#, newtype in Haskell, inline classes in Kotlin)
Units of measure (a way to encode dimensional analysis into the language)

There are shades between some of these (e.g. placeholder type declarations - kind of variant of opaque types that fall back to an implementation type), and then there are different directions that blend each of these together.

@RyanCavanaugh had a great analogy about this where 3 kids are asking their parents for a pet. One wants a dog, one wants a cat, one wants a fish. They ask their parents "when are we getting a pet!?" Clearly they all agree they want a pet, but each wants a different pet!

Do I like branded types? I do! Branded types achieves something like distinct aliases, and fits the bill for what most users are looking for. But I don't think that's the right way to think about it. There's more design space to be fleshed out with plenty of known tradeoffs, and nothing giving me a sense that we need to rush a solution ASAP.

ExE-Boss commented 4 years ago

I’d like if we could get https://github.com/microsoft/TSJS-lib-generator/pull/858 into TypeScript 4.0.

benjamingr commented 4 years ago

@DanielRosenwasser first of all thank you for the writeup 🙇

Can you elaborate a bit on what use cases nominal types actually address for TypeScript?

First: feel free to send me to a giant wall of text or a repo and I'll read it :]

I don't mean opaque types like placeholder types - I mean what you call "Traditional" nominal types.

I always felt nominal types were antithetical to JavaScript and that's why previous attempts didn't really work so well. There are ways to make it work pretty nicely (protocols in swift and typeclasses in haskell come to mind as "Nominal but extendable from the outside") and I'm sure you're familiar with most of the "well established" ways (I assume "units of measure" is an F# wink).

I have found a lot of people asking for nominal (as in "traditional") types but not a lot of writeups about why.

DanielRosenwasser commented 4 years ago

Over time, we've seen fewer and fewer people request "traditional" nominal types, maybe because collectively the community has built up a mental mode for structural types. There are some places where types truly do act nominally (when instanceof is involved or when there are privates). Some of that is captured with better control flow analysis and compatibility checks, but it's not perfect.

Some of the "traditional" use-cases are the same as those of a zero-overhead nominal wrapper type (e.g. newtype), and a lot of the time the intent there is to ensure special handling for things like file paths, untrusted strings, etc.

chyzwar commented 4 years ago

I kind of feel that Typescript is already expressive enough. What I would personally would like to see is better tooling integration.

Because of above it is common to see clunky and hacky solutions. Most react projects have babel included for react-hot-loader (compiler plugins), some CSS systems also require babel for compile time transforms. Using pnp, esm or even CSS modules require more tooling and workarounds for tsc limitations.

It is also frustrating that for some of these issues community came with concrete solutions in form of PRs or proposals but these were rejected or stalled for years. As a practitioner, it is getting harder to use TS in the context of wider ecosystem.

Anyway I am just random person from internet.

JoshuaKGoldberg commented 4 years ago

@DanielRosenwasser maybe https://github.com/microsoft/TypeScript/pull/29374 could get reviewed in time for 4.0? I think it covers many (most?) of the this-before-super cases folks tend to ask about.

mathiasrw commented 4 years ago

Please reconsider including support for referencing ES modules with a file path including the file extension. It will give a big boost to level the playing field of multi-environment code.

https://github.com/microsoft/TypeScript/issues/16577

qlonik commented 4 years ago

Thank you for your focus on the tooling around typescript! I was hoping you could consider providing closer integration with https://github.com/microsoft/tsdoc. A lot of other modern languages like go and rust provide documentation tooling right out of the box and encourage developers to write standard comments, but typescript is lacking in this regard.

zen0wu commented 4 years ago

It would be super great if #31445 can be picked up, this has been a deal breaker for us and I believe a lot of people (based on how many references that issue has)!

ExE-Boss commented 4 years ago

Can https://github.com/microsoft/TypeScript/pull/38967 be included in TypeScript 4.0, and maybe also https://github.com/microsoft/TypeScript/pull/35608.

Jack-Works commented 4 years ago

I found people are requesting everything to be included in the 4.0 release 😆

canonic-epicure commented 4 years ago

Feels like TS is loosing momentum? Nullish coalescing and short-circuiting assignments for the next, major, 4.0.0 release? No big goals and ambition ideas anymore?

For the next major, I'd expect:

Higher kinded typing
Dependent typing? Type-level functions? (Ok, this one can be for 5.0.0)
Nominal typing
Macroses
Support for transformers in tsconfig.json
Compilation to WASM (of some language subset)

Shinigami92 commented 4 years ago

@canonic-epicure Agree, currently it feels more like a 3.10 for the next version

Jack-Works commented 4 years ago

Feels like TS is loosing momentum? Nullish coalescing and short-circuiting assignments for the next, major, 4.0.0 release? No big goals and ambition ideas anymore?

TypeScript doesn't follow the semver. There isn't v0.10, v1.10, v2.10, or v3.10. So this is actually a normal milestone. It's a bit strange people are expecting so many changes in 4.0 but not saying anything in 3.9 or prior iteration plan. 🙈

Jack-Works commented 4 years ago

Type-level functions

type X<T> = T can do it on some level. (not supporting higher-order functions.)

Macroses

IMO it does not satisfy the Typescript's goal.

Support for transformers in tsconfig.json

Have a try: https://github.com/cevek/ttypescript

Compilation to WASM (of some language subset)

Do you looking for https://www.assemblyscript.org/

canonic-epicure commented 4 years ago

Ok, so 4.0.0 is just a next minor release, good to know.

Regarding the "macroses do not satisfy the TS goal" and "use ttypescript for transformers" (ts-patch works better btw) - this resembles the jedi move - "this is not the feature you need". No, macroses and transformers out of the box please. Its been requested years ago.

Jack-Works commented 4 years ago

I also want marco in TypeScript but there're really many reasons against this.

if Marco can generate different JavaScript code, it's creating a new non-type level syntax, therefore it's an extension to the ES spec. enum, import x = require(...), module is the exception of this rule but they come from the early time of TypeScript.
if you want to use Marco cross different files to generate different JS files, then it's impossible to dumbly drop all type syntax to get the JavaScript file.
Marcos can increase the analysis & compile time, and likely to be abused.
If Marco can emit different JS files based on the type info, it will make Babel impossible to handle this syntax. So this behavior is violating the isolatedModules rule (exception: const enum and module)
If Marco can only do a "type level Marco" and can be erased by Babel safely, it becomes much useless but still useful for higher-order / programmatic types. Therefore it is not violating any goals, but I'm doubting if the TypeScript team will interest in the idea. (I have made a demo at https://github.com/Jack-Works/typescript-marco-demo/blob/master/marco-test.ts).

canonic-epicure commented 4 years ago

@Jack-Works I don't understand your points. Perhaps you mean that macroses will extend parser and create new synatx?

For me, macros is just AST -> AST function, that runs prior typechecker somehow, therefor it can create new AST nodes that will be typechecked regularly. It does not create new syntax however - the input is regular AST, the output too. It does create new nodes in AST.

The discussion will be off-topic for this thread, perhaps to be continued on #compiler channel in discord?

xiaoxiangmoe commented 4 years ago

Can #38597 be included in TypeScript 4.0 ？

wongjiahau commented 4 years ago

@DanielRosenwasser

undefined on index signatures is an example of something that's interesting, but we don't want to add behavior that makes it harder for 90% of people who already operate under the current assumptions.

Just curious how do you know it's 90% of the people?

DanielRosenwasser commented 4 years ago

@wongjiahau the number was made up casually for the sake of explanation. Not sure if that's the specific point you're asking about.

DanielRosenwasser commented 4 years ago

Just as a heads up people: our team won't be working on June 19th, so we'll be pushing the schedule over a bit. The beta is now slated to ship by next Thursday, June 25th.

wongjiahau commented 4 years ago

@DanielRosenwasser I'm trying to point out that you are using some made-up arbitrary numbers to deny the importance of the feature (#13778) that clearly aligns with the first objective of Typescript, which is to Statically identify constructs that are likely to be errors.

Please don't get me wrong, I appreciate that the hard work that have been put into this project by the core team, but I just think that we could have made it better if we can be truly align with the objectives of this project instead of allowing unproven statements to hinder its advancement.

RyanCavanaugh commented 4 years ago

@wongjiahau we didn't go into a meeting and say "Daniel said the number is 90%, that's above our threshold of 85%, let's never do this feature". We're still investigating it and we're very aware of dev demand for it, but we've also tested out what this feature looks like in practice and I can tell you that it's not pretty.

If you're going to overanalyze statements like this from us like this, you're just going to get fewer statements from us, because we have better things to do than get actively misinterpreted on the internet.

Kingwl commented 4 years ago

4.0 is definitely a milestone rather than "the next version of 3.9".

DanielRosenwasser commented 4 years ago

@typescript-bot create release-4.0

typescript-bot commented 4 years ago

Heya @DanielRosenwasser, I've started to create the release-4.0 branch for you. Here's the link to my best guess at the log.

wgebczyk commented 4 years ago

@Kingwl if this is milestone, then what are those big things or at least what is the Hero Feature? I do not see anything such great thing in Language Feature list at the top of this issue. Nothing unusual comparing to most of 3.x releases. Of course you might say that it is just breaking change that requires release of major version, but then it is hard to call it "milestone".

xiaoxiangmoe commented 4 years ago

@wgebczyk In my opinion, variadic tuples with labeled tuple elements is the milestone.

Kingwl commented 4 years ago

@wgebczyk Never mind. But actually Variadic Tuples is.

wgebczyk commented 4 years ago

@xiaoxiangmoe @Kingwl mile-stone? inch-stone.

mk0y commented 4 years ago

It's there: https://devblogs.microsoft.com/typescript/announcing-typescript-4-0-beta/#variadic-tuple-types When will this reach stable version? I can't wait to apply this in every day coding in VS Code.

j-oliveras commented 4 years ago

@mk0y according to opening message about August 18th.

RyanCavanaugh commented 4 years ago

@wgebczyk our releases are time-based; each release contains approximately three months of the team's work. Our milestone versioning policy (n = n + 0.1) has been consistent for the past 20 releases so hopefully this will stop being a surprise to people at some point 😅

SancheZz commented 4 years ago

Would you consider allowing symbol type for indexing in the next minor releases? Could you actualize and merge the pull request 26797?

typescript-bot commented 4 years ago

Heya @DanielRosenwasser, I've started to update the version number on release-4.0 to 4.0.1-rc for you. Here's the link to my best guess at the log.

DanielRosenwasser commented 4 years ago

@typescript-bot sync release-4.0

typescript-bot commented 4 years ago

Heya @DanielRosenwasser, I've started to sync release-4.0 with master for you. Here's the link to my best guess at the log.

DanielRosenwasser commented 4 years ago

@typescript-bot sync release-4.0

typescript-bot commented 4 years ago

Heya @DanielRosenwasser, I've started to sync release-4.0 with master for you. Here's the link to my best guess at the log.

DanielRosenwasser commented 4 years ago

@weswighammmmmmmmmmmmmmmmmmm, the bot hates me ): ): ): ):

Absolutely no rush, but I did it manually and filed this: https://github.com/microsoft/TypeScript/issues/39869

timreichen commented 4 years ago

Is there already a roadmap for after 4.0 somewhere? I would like to boost #37582 since there is a more and more growing demand (#39965, #38149, #27481, #39965, #38546). It looks like a reasonably scoped issue to me.

DanielRosenwasser commented 4 years ago

Just as an update, we had to move over the RC by 2 days for the website launch and for other changes we felt we needed to land in the RC. We don't anticipate anything pushing us back much further, but to be safe, we'll be giving ourselves another 2 days to get feedback on the RC, and aiming for the 20th instead.

microsoft / TypeScript