Not to take anything away from your larger point, but TypeScript doesn't have not casting, it has type assertions. This matters because casting means "turn it into this type", which generates code. A type assertions only means "assume it's this type". It gets removed at compile time, plus any intermediate variables you might need to create to avoid the occasional type assertion monstrosity will be appropriately cleaned up by any minifier.

In short, I strongly doubt that the need for type assertions would meaningfully impact jQuery file size.

Thanks for the terminology fix. With lots of these assertions, especially in the form of `x as unknown as TheProperType` we wouldn't have to increase file size but that would nullify most of the TypeScript gains and would make the code more readable. If we wanted to make internal code more in line with what TypeScript expects, that would require code changes which I expect may increase the file size, though.

I haven't done any real testing on the jQuery code base but that's my experience working on some TypeScript projects.

Not everything can be handled by a minifier. Consider multiple accesses of `item.prop` where `prop` is optional. You can cache `item.prop` in a variable to avoid multiple checks but the minifier usually cannot revert it back to the previous form as it has to take into account the possibility that `item.prop` is a getter in which case such a replacement would potentially change semantics.

> Plus, that would be a barrier for some contributors

A good point considering the scope of jQuery and its user base. I don't know much about generating larger file sizes but the community contribution aspect isn't something I considered.