Hacker News Reader

Comment by johnfn | Hacker News Reader

Sometimes at work I can't figure out some TS type and start thinking it's impossible. Then I remember that repos like this exist, and if some guy really managed to parse Typescript types in Typescript, that my problem is peanuts compared to that.

That usually motivates me to solve my problem.

View on HN

On the flip side, if you can't find a close enough type definition with reasonable effort, it's often a sign that you're about to enter gibberish type territory and it might be time to reconsider. Even if a type does exist in the end, it might be unparseable to every human on your team, future you included.

This. I regret every use of `infer`, save for one instance in which it actually helped, but it was a side project anyway.

Being stuck in the typing rabbit hole for more than X minutes is a free pass to // @ts-ignore that one problematic line in the middle (particularly when it's "these objects I'm merging add up to the expected thing, but it would take a mountain of spaghetti to make TypeScript understand this")

.. or just

    type MergedType = TypeA & TypeB

This infamously does not work for factories though, or has that changed since I last checked? Typescript is great, but there are a number of places where it isn't quite there.

This would get bounced where I work. No way we would allow this.

9.9/10 cases there is a design flaw happening here, I and others I work with have found this to be true. We have zero // @ts-ignore statements in a very large code base that dozens of developers work with every day.

Using interface extensions properly helps tremendously here

This is too severe. There are reasons to need // @ts-ignore. Probably the biggest one in my experience is the inability to type functions with conditional return statements[1].

Probably a good rule of thumb is that you get to use a ts-ignore if you can link it back to an open issue on the TS repo :)

[1]: https://github.com/microsoft/TypeScript/issues/33912

I have yet to run into someone who couldn't actually resolve the issue by approaching the problem in a different way. Its why I said 9.9 not 10/10, as this would be a case where would have to comment liberally, but yeah, file an issue with the repository and go from there.

That said, I haven't run into this in my many years of working with TypeScript except once.

C'mon man. Just one more type, and then the whole repo will be sound. Just one more type. Just one tiny little `infer`. What could possibly go wrong?

Some things are still impossible. I lost count of the bugs I reported to TS only to be told that "works as intended" or that it's a "design limitation."

There was even a guy who got Doom running entirely in TS types[0].

[0]: https://www.youtube.com/watch?v=0mCsluv5FXA

I sometimes get irritated that many new consulting projects nowadays make use of nodejs, instead of Java or .NET.

Then for a few seconds I remember the names behind Typescript's design, its type system capabilities, and a possible excuse to use C++ via addons, and it kind of lightens my day.

that's funny, it motivates me to type `any`

That would motivate me to refuse your PR and help you come up with a better solution.

There are legit cases for `any` where it doesn't detract any type safety at all but the number of people that understand them is very small (fully convinced 99% of TypeScript devs doesn't even know most of the things in the official docs).

Reply on news.ycombinator.com