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 4.1 Iteration Plan #40124

Closed
DanielRosenwasser opened this issue Aug 18, 2020 · 53 comments
Closed

TypeScript 4.1 Iteration Plan #40124

DanielRosenwasser opened this issue Aug 18, 2020 · 53 comments
Labels
Planning Iteration plans and roadmapping

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Aug 18, 2020

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

Editor Productivity

Performance

Infrastructure

  • Improve Workflow for External Code Tests
  • Breaking Change Detection Scripts
@DanielRosenwasser DanielRosenwasser added the Planning Iteration plans and roadmapping label Aug 18, 2020
@DanielRosenwasser DanielRosenwasser pinned this issue Aug 18, 2020
@Kingwl
Copy link
Contributor

Kingwl commented Aug 19, 2020

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

@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Aug 19, 2020

Fixed, thanks!

@ifiokjr
Copy link

ifiokjr commented Aug 21, 2020

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

Kingwl commented Aug 21, 2020

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

You can see It here: #39669 (comment)

@MathiasKandelborg
Copy link

MathiasKandelborg commented Aug 21, 2020

How about some basics?

#19573

@Xample
Copy link

Xample commented Aug 25, 2020

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

ghiscoding commented Aug 27, 2020

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

DanielRosenwasser commented Aug 27, 2020

@ghiscoding done!

@dbartholomae
Copy link

dbartholomae commented Aug 28, 2020

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

DanielRosenwasser commented Sep 13, 2020

@typescript-bot create release-4.1

@typescript-bot
Copy link
Collaborator

typescript-bot commented Sep 13, 2020

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

DanielRosenwasser commented Sep 15, 2020

@typescript-bot sync release-4.1

@typescript-bot
Copy link
Collaborator

typescript-bot commented Sep 15, 2020

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

weswigham commented Sep 15, 2020

@typescript-bot sync release-4.1

@typescript-bot
Copy link
Collaborator

typescript-bot commented Sep 15, 2020

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

weswigham commented Sep 15, 2020

@typescript-bot sync release-4.1

@typescript-bot
Copy link
Collaborator

typescript-bot commented Sep 15, 2020

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

DanielRosenwasser commented Sep 17, 2020

@typescript-bot sync release-4.1

@typescript-bot
Copy link
Collaborator

typescript-bot commented Sep 17, 2020

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

Skillz4Killz commented Nov 5, 2020

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

@ExE-Boss
Copy link
Contributor

ExE-Boss commented Nov 6, 2020

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

Skillz4Killz commented Nov 6, 2020

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

@mprobst
Copy link
Contributor

mprobst commented Nov 10, 2020

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

Skillz4Killz commented Nov 10, 2020

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

mprobst commented Nov 10, 2020

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

RyanCavanaugh commented Nov 10, 2020

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

RyanCavanaugh commented Nov 10, 2020

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

@mprobst
Copy link
Contributor

mprobst commented Nov 10, 2020

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

Skillz4Killz commented Nov 10, 2020

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

DanielRosenwasser commented Nov 11, 2020

Thanks for understanding!

@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Nov 15, 2020

@typescript-bot bump release-4.1

@typescript-bot
Copy link
Collaborator

typescript-bot commented Nov 15, 2020

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

DanielRosenwasser commented Nov 18, 2020

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 DanielRosenwasser unpinned this issue Nov 19, 2020
oliviertassinari added a commit to mui/mui-x that referenced this issue Nov 22, 2020
@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Dec 10, 2020

@typescript-bot bump release-4.1

@typescript-bot
Copy link
Collaborator

typescript-bot commented Dec 10, 2020

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

DanielRosenwasser commented Jun 16, 2021

@typescript-bot bump release-4.0

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jun 16, 2021

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

DanielRosenwasser commented Jun 16, 2021

🤦‍♂️

@typescript-bot bump release-4.1

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jun 16, 2021

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

DanielRosenwasser commented Jun 16, 2021

@typescript-bot bump release-4.1

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jun 16, 2021

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.

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

17 participants