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.
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.
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")
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 :)
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.
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.
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."
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 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).
For those not familiar with this kind of computing challenges, I must link this wonderful video about TypeScript types running... DOOM. https://www.youtube.com/watch?v=0mCsluv5FXA
If folks are interested in this sort of thing, but want to play around with higher order building blocks, http://hkt.code.lol may be worth checking out.
In addition to type-level analogues of your normal Lodash-esque functions, it includes a suite of type-level parser combinator utilities and is built on higher-kinded type abstractions.
I once went really deep into fancy, fun generic Typescript types (think the kind of type that can verify whether a string is written in "SpongebobMemecase" like "tHiS" vs "this"), and Typescript types can and do use ternary and rest operators
I took a look at the source for the attached repository - the parser is in fact clearly written as a generic type. The presence of ?, :, and ... operators represent conditional types and tuple level destructuring respectively.
This is a very impressive project in my view - it's baffling that you would have the wherewithal to link the discussion you did but not realize the novelty here.
It’s not broken. You just don’t see what others do. Top-level await is very nice for the realm of making quick and dirty scripts or even just working in a REPL. The good news is that you won’t be forced to use it.
But it is possible, and i have seen code like this (admittedly, not as complex) in production. When you have code like this is really hard to know what is really going on. Its SUPER rare you need flexibility like this in your type system, and as we all know when its doable, people will abuse it like crazy.
That usually motivates me to solve my problem.
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
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
That said, I haven't run into this in my many years of working with TypeScript except once.
[0]: https://www.youtube.com/watch?v=0mCsluv5FXA
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.
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).
In addition to type-level analogues of your normal Lodash-esque functions, it includes a suite of type-level parser combinator utilities and is built on higher-kinded type abstractions.
https://github.com/sinclairzx81/typebox#syntax
Can you run your whole payroll app at compile time via TypeScript types too?
HN thread on this here: https://news.ycombinator.com/item?id=43184291
https://github.com/Microsoft/TypeScript/issues/14833
This is a very impressive project in my view - it's baffling that you would have the wherewithal to link the discussion you did but not realize the novelty here.
Everytime i hear Ocaml has a complex type system i refer them to Typescript.