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

Fixed, thanks!

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.

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

You can see It here: #39669 (comment)

How about some basics?

#19573

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.

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 😃

@ghiscoding done!

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.

@typescript-bot create release-4.1

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.

@typescript-bot sync release-4.1

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.

@typescript-bot sync release-4.1

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.

@typescript-bot sync release-4.1

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.

@typescript-bot sync release-4.1

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.

@typescript-bot bump release-4.1

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.

@typescript-bot sync release-4.1

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.

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.

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

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.

The Breaking Changes section should probably include #38967.

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

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

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

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.

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

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

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

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

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

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.

Thanks for understanding!

@typescript-bot bump release-4.1

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.

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