I'd disagree with that - and say this scenario is where TypeScript saves me time.
I just want to add a property to an object. All I have to do is add it to the definition, and TS will show me every location I have forgotten to set the Bar property, which means I can be confident it is set, so I do not need to write extra code that tests whether Bar is set.
> TS will show me every location I have forgotten to set the Bar property
Yeah this is what I was getting at - e.g. say I have 5 functions that all return Foo object, and for just one of them I need to add in an extra Bar property then I need to make sure that all 5 functions also do the Bar property, even if only 1 needs it (or make it optional, but that might screw with the semantics of the one function that does need it). So now I have a Bar on all Foos, even though only 1 function needs it - things start to get messy.
The alternative to changing all 5 functions is just to create a separate type for just that one function that needs Bar
Either way it is "extra work" if you are used to the fast and lose javascript way of just adding it there and then and not caring about the others.
I agree though that TypeScript is way superior as you point out it would just tell you where you screwed up and I would always start with a new TS project rather than JS today, but I still think there is a place for the raw & dangerous world of untyped JS for rapid and unsafe prototyping and hacking where TS can slow you down.
I just want to add a property to an object. All I have to do is add it to the definition, and TS will show me every location I have forgotten to set the Bar property, which means I can be confident it is set, so I do not need to write extra code that tests whether Bar is set.