Giters

microsoft / TypeScript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

Home Page:https://www.typescriptlang.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

TypeScript 4.1 Iteration Plan

DanielRosenwasser opened this issue · comments

commented

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
commented

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

commented

Fixed, thanks!

commented

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.

commented

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

You can see It here: #39669 (comment)

commented

How about some basics?

#19573

commented

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.

commented

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 😃

commented

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.

commented

@typescript-bot create release-4.1

commented

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.

commented

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.

commented

@typescript-bot sync release-4.1

commented

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.

commented

@typescript-bot sync release-4.1

commented

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.

commented

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.

commented

When will TypeScript 4.1 Beta Release ?

commented

@xiaoxiangmoe you can use nightly or in meanwhile:

4.1.0-beta 13 hours ago

See Versions from https://www.npmjs.com/package/typescript to get more information about builds.

commented

@DanielRosenwasser Hello 👋 sorry to bother you but I was hoping to request that future blog posts for this release the wording on the --noUncheckedIndexedAccess could be redone.

https://devblogs.microsoft.com/typescript/announcing-typescript-4-1-beta/#no-unchecked-indexed-access

  • Using Pedantic in the blogpost goes against the discussions we've already had about not using pedantic.
    image

image

There have been entire issues on this repo dedicated to picking a name that did not imply pedantic. Having this in the blogpost after all this is not really nice.

  • The explanation of this property does not really do it justice in my opinion.
    Every other feature on the changelog "Use this immediately, will help fix stuff! It's amazing"
    Index: "This causes too much noise and doesnt really fix much"

For example, the post mentions nothing of how impactful this change is to array destructuring. Numerous issues have been created on this repo for this problem such as #38287 #40749 #36635 #37045 which shows that this is quite a useful change to many TS users.

The major downsides that have been seen for those that have tested this is only in older legacy code where people use for loops. A lot of more recent code will not be using for loops like this except when every millisecond of performance matters and so therefore the biggest issue of this config isn't even that big an issue for majority of relevant code.

The post mentions nothing of how this option has been shown already to be improving performance and preventing runtime bugs which cause hours of debugging because the typings will not show any errors so you are forced to go line by line to figure out some bug in production. Nor does it mention that this is quite possibly one of if not the most request feature to TS and has been requested for years now. IMO the blog post should be encouraging the use of this option not discouraging it such as mentioning that the slightly extra noise created by this option is WELL worth the benefits gained from it.

commented

I'll reconsider how it's phrased in the 4.1 RC/Final blog posts - you might be right that the tone deserves more optimism. But I'll reiterate that the feature is currently (currently) not one that the core team can definitely recommend that everyone uses. While we're open to changing our minds about this, and while the feature might improve in functionality over time, we're being intentionally being cautious in our tone to set expectations.

commented

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

commented

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.

commented

I think I'm running into this issue which is affecting a number of packages, in our case it began with 4.1.0-dev.20201029 (my comment here).

Prior to that all of our code was building ok with 4.1.0-beta.

commented

You'll have to be more specific - that is just an automated test run.

commented

I linked to my comment on that Issue which has playground links with a specific before and after example that fails in 4.1.0-dev.20201029 and succeeds in 4.1.0-dev.20201028.

Comment link: #41359 (comment)

The selection of type overloads for node's promisify changes resulting in an error where there was not one previously.

I might be falsely associating it with the Issue in question, but the timing and the nature of some of the error messages makes me think they are related. Let me know if you'd like a fresh Issue.

commented

The Breaking Changes section should probably include #38967.

commented

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

commented

@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!

commented

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

commented

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.

commented

@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?

commented

@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.

commented

@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!

commented

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

commented

@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).

commented

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.

commented

Thanks for understanding!

commented

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.

commented

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

commented

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.

commented

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.

commented

🤦‍♂️

@typescript-bot bump release-4.1

commented

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.

commented

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.