Ryan Cavanaugh comments

Results 416 comments of


                                            Ryan Cavanaugh

trafficstars

references between different namespaces

The library doesn't automatically determine a correctly-qualified name when there's a reference to another type. It's more of a feature request than a bug, and a rather complicated one at...

Are transpilers adding + core.js invalid?

The comparison to "Chrome + core.js" is irrelevant. Chrome is a _runtime_ and needs to support these things natively -- the web is not going to move forward if every...

Write about Flow not accepting more strict Arrays

Probably good to talk about Flow's treatment of mutated arrays in the same section: ```js const arr = ['1', 0]; arr.sort(); // Error in TS, not in Flow, throws at...

Write about Flow not accepting more strict Arrays

> Flow, on the other hand, will show an error in this case. Only because tuples are read-only. The equivalent TS code would be: ```ts const arr: ReadonlyArray = ['1',...

Write more about Object definition differences for the same code

Perhaps there's a useful row in the initial table based on this discussion | | TypeScript | Flow | | ------------- | ------------- | ----- | | Design Goal |...

"moduleResolution": "NodeNext" throws ESM related errors

It sounds like you had a misconfiguration and fixed it. I don't see a demonstrated bug here.

Class method with conditional return type cannot return types common to both conditional branches when the class also has an interface

Duplicate #27932 You can write ```ts public bar(): number | (T extends string ? string : never) { ```

Class method with conditional return type cannot return types common to both conditional branches when the class also has an interface

I missed that - no, that's super weird

Class method with conditional return type cannot return types common to both conditional branches when the class also has an interface

Declaration merging, for declaring when you've e.g. polyfilled `foo` onto the `Foo.prototype`

TS does NOT understand the condition will always be true

One of the design principles of `any` is that, to the greatest extent possible, it should be impossible to get a type error in an expression involving `any`