A parser for TypeScript types, written in TypeScript types | Hacker News Reader

A parser for TypeScript types, written in TypeScript types

github.com

77 pointstodsacerdoti39 comments

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.

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."

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?

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

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

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).

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.

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.

How does it compare to TypeBox?

https://github.com/sinclairzx81/typebox#syntax

Pretty sure this is a joke/demo for the power of type scripts typing system

See also this, TS types as a parser combinator: https://github.com/sinclairzx81/parsebox

I thought we have C++ for meta-meta-meta-meta programming...

Can you run your whole payroll app at compile time via TypeScript types too?

You can run doom in TypeScript types.

This is actually not a joke.

HN thread on this here: https://news.ycombinator.com/item?id=43184291

I'm sure OP wasn't joking and was referring to the same thing.

Im sure it was obvious to op, but possibly not to everyone else in this thread.

FYI, TypeScript's type system is turing-complete.

https://github.com/Microsoft/TypeScript/issues/14833

Has Doom been implemented yet in TypeScript types?

Typescript looks more and more like a cult

(removed)

TypeScript (the types part) absolutely does have ternary operators: https://www.typescriptlang.org/docs/handbook/2/conditional-t...

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.

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

<Sorry, wrong thread>

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.

Where those quotes come from?

This is actually WHY i think typescript is going downhill. I feel the sweetspot was around 2.x (iirc) when things like this was not possible.

Everytime i hear Ocaml has a complex type system i refer them to Typescript.

Nobody is forcing you to write TypeScript like this...

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.

You DO need this flexibility in your type system when the underlying language is dynamic.

Reply on news.ycombinator.com