TypeScript 4.1 Iteration Plan

[DanielRosenwasser]

This document outlines our focused tasks for TypeScript 4.1. Nothing is set in stone, but we will strive to complete them in a reasonable timeframe.

Date	Event
August 20th	TypeScript 4.0 Release
September 11th	Create 4.1 Beta (4.1.0) Build for Testing
September 15th	TypeScript 4.1 Beta Release
October 30th	Create 4.1 RC (4.1.1) Build for Testing
November 3rd	TypeScript 4.1 RC Release
November 13th	Create 4.1 Final (4.1.2) Build for Testing
November 17th	TypeScript 4.1 Final Release 🚀

Language Features

• Recursive Conditional Types
• Investigate Pedantic Flags
  • undefined in index signatures
  • --noImplicitOverride
• Investigate Preventing Global Conflicts with Strict Environment Configuration
• Investigate Key Augmentations in Mapped Types
• Investigate ESM Interop
• export * as default
• Investigate WASM imports
• JSX Factory Updates
• Investigate /// Comments

Editor Productivity

• New Semantic Highlighting API
• Enable running TSServer in a worker thread
• Hierarchal Refactoring Triggers
• Improve Refactoring Discoverability
• JS Inference Improvements
• Investigate Support for @see and @link Tags
• ATA Updates

Performance

• Anticipated bug fixes and UX improvements for partial semantic mode
• tsc Profiling Output Support
• Investigate Slowdowns in Popular Libraries

Infrastructure

• Improve Workflow for External Code Tests
• Breaking Change Detection Scripts

[Kingwl]

NIT:
undefined in index signatures --noImplicitOverride referenced same issue.

[DanielRosenwasser]

Fixed, thanks!

[ifiokjr]

I want to give a huge shout out to the TypeScript team. You've just released an amazing 4.0.2 and you're already getting us excited for the next thing around the corner. As a burgeoning open-source developer it's inspiring, and you deserve all the success and praise.

I'm most excited about the potential introductions of /// comments and the override keyword.

[Kingwl]

@ifiokjr
Hey. How about get a preview and perhaps sends some feedback for the override?

You can see It here: #39669 (comment)

[MathiasKandelborg]

How about some basics?

#19573

[Xample]

Hi, another missing feature I have been awaiting for a long time is the typed errors.

As I wrote in a comment

This is the only feature I envy the java language

The issue is still labeled "Awaiting More Feedback", in my opinion there is not need to reinvent the wheel, if we can get some interest from the TS team I would with pleasure clarify possible use case scenario.

[ghiscoding]

Can someone add the Iteration link to the Roadmap?
That would avoid me couple clicks each time I want to check the plan 😉

Thank You.... TypeScript is getting more awesome every iteration 😃

[DanielRosenwasser]

@ghiscoding done!

[dbartholomae]

Would love to see some progress on nominal types (#202) for 4.1. I'm happy to help, but unsure how to do this. I posted some more details in #202 to keep this thread clean.

[DanielRosenwasser]

@typescript-bot create release-4.1

[typescript-bot]

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

[DanielRosenwasser]

@typescript-bot sync release-4.1

[typescript-bot]

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

[weswigham]

@typescript-bot sync release-4.1

[typescript-bot]

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

[weswigham]

@typescript-bot sync release-4.1

[typescript-bot]

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

[DanielRosenwasser]

@typescript-bot sync release-4.1

[typescript-bot]

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

[Skillz4Killz]

Sad to see the wording on the post has not changed 😞

[ExE-Boss]

@Skillz4Killz
The last paragraph has been changed from:

This flag can be handy for catching out-of-bounds errors, but might be noisy for a lot of code, so it is not automatically enabled by the --strict flag.

to:

This flag can be handy for catching out-of-bounds errors, but it might be noisy for a lot of code, so it is not automatically enabled by the --strict flag; however, if this feature is interesting to you, you should feel free to try it and determine whether it makes sense for your team’s codebase!

[Skillz4Killz]

@ExE-Boss That changes nothing of the tone and understanding of this property.

[mprobst]

To add some data to this conversation, we tried 4.1 and --noUncheckedIndexedAccess on a substantially sized code base. We found that it broke ~15% of "targets", where a target has the granularity of typically a single or few UI component(s). These targets broke individually, i.e. 15% of targets had a compilation error in themselves, not just in some of their dependencies.

Our takeaway is that this flag might be interesting, but currently the signal/noise ratio (i.e. the number of genuine issues caught as opposed to false positives) does not warrant the effort it'd take to roll this out, nor the ongoing effort for programmers to handle the false positives.

[Skillz4Killz]

@mprobst That is some amazing info!

Out of curiosity how much more info can you extrapolate from your use. For example, if I took a large-sized code base in non-strict TS and enabled the "strict" flag a lot of % of targets would break as well. That should not discourage users from being encouraged to be more type-safe? Breaking older code without this flag is expected, the main concern IMO is how many are actually false positives?

What was the signal/noise ratio? How was this calculated and determined whether each one is a signal or a noise?

[mprobst]

@Skillz4Killz I manually sampled some of the results. Among 10 randomly chosen targets, I found 10 false positives, i.e. the code was either obviously correct (e.g. access within for loop, guarded by length check, generally reasonable array operations, etc) or it was covered by a test and working as expected (such as getting element #3 on a page that in practice is guaranteed to have 3 elements on it). I'm sure there are positive positives, they might just be very hard to find amongst the large number of false positives.

The code repository this runs on is google3, see here for some more background on the size and scale. Meaning we have a very large sample of code, and most of it is well tested and running in production (i.e. works in practice). The number of occurrences is difficult to compare with other checks given the prevalence of array indexing in code in general, but 15% of targets broken is at least two orders of magnitude more frequent than I'd expect for a high precision check.

[RyanCavanaugh]

@Skillz4Killz A couple points on this

First is that we want to manage expectations appropriately. For noUncheckedIndexedAccess, there are a lot of cases ("standard" C-style for loops, accesses explicitly guarded by .length checks, accesses immediately following a push, etc) that simply don't work as ergonomically as the rest of TypeScript. For codebases that are willing to write code in a way that doesn't encounter those limitations, this is obviously fine, but lots of existing code out there is filled with patterns for in-bounds access that TS will not recognize.

Second, your own willingness to do the work to turn this on in your codebase is admirable! The general upgrade philosophy of TypeScript, though, is that medium-to-large efforts like that should not be part of the "normal" upgrade process. This informs how we choose our default options and how we roll out new behaviors that might conflict with that philosophy.

We are not discouraging anyone from turning this on, we're just being honest about the limitations we think most people are likely to encounter. I would hope people would find that attitude laudable. The fact that we added the feature at all is a testament to the value we see in it!

[RyanCavanaugh]

@mprobst that's some great context. I'm currently sweating bullets on the Promise change (0.290%) being too disruptive 😅

[mprobst]

@RyanCavanaugh the Promise change is not so bad actually, we can fix that with automated machinery by inserting appropriate as any casts. The scary ones are the changes that cannot be automated. Also, it might help that this is the 25th Google-wide TS language upgrade we're doing (we skipped one minor version once, but otherwise have been tracking TS since 1.4).

[Skillz4Killz]

Very interesting points. I didn't think there would be that many false positives. Hmmm, that makes me think you guys are correct on the wording to set expectations. I will continue trying to advocate enabling this in my work but i 100% can understand now why it's worded as is now.

[DanielRosenwasser]

Thanks for understanding!

[DanielRosenwasser]

@typescript-bot bump release-4.1

[typescript-bot]

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

[DanielRosenwasser]

Hey all, we're going to retarget to Thursday (11/19) just to ensure that everything is working as optimally as possible and documented.

[DanielRosenwasser]

@typescript-bot bump release-4.1

[typescript-bot]

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

[DanielRosenwasser]

@typescript-bot bump release-4.0

[typescript-bot]

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

[DanielRosenwasser]

🤦‍♂️

@typescript-bot bump release-4.1

[typescript-bot]

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

[DanielRosenwasser]

@typescript-bot bump release-4.1

[typescript-bot]

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