[semicolon_storm]

Is this what modern idiomatic TS looks like?

Reading through the pipe implementation, as someone who primary works in the relatively "boring" world of backend languages, this looks like the kind of code that would get shot down review for being too clever and not very readable, regardless of how "elegant" it may be.

Using triple assignments (a = b = somevalue)? Using λ as a type name instead of writing out lambda with symbols that are actually easy to type? Overloading/reusing variables that makes it hard to mentally trace how data flows through?

[upzylon]

Chaining assignments and using non-ascii characters as variable names is definitely not the norm in most TypeScript projects I've seen and worked on.

When I started this project it was just for my own personal use and kind of a creative / intellectual outlet for me where I didn't have to make any compromises and adhere to anyone else's style. So to this day some of the code might be a bit... exotic. It's definitely not how I'd write it in my day job.

That's the JS part. The type-definitions I'm afraid are just unreadable because it's TypeScript. I feel they're like regexes in that regard: write once and try not to touch them again.

[jackblemming]

Why does it matter how complicated it is if you’re not the one maintaining it? Your head would probably spin if you saw how complicated the database code you use is, as a backend dev.

[semicolon_storm]

Some domains require horribly complicated code that I’m perfectly happy admitting that I’ll never understand it. Chaining function calls is not one of those domains.

I suppose I don’t really care, it’s not my library and I’ll never use it, it’s just interesting to see how differently styled it is.

[cobertos]

Chaining functions _does_ need this though, in current Typescript. The pipe function has to enforce some really complex constraints (inner types between siblings/fn args). There's really no other "correct" way to write this without calling it a day and just doing a generic for different amount of args (<A>, <A, B>, <A, B, C>, etc).

I agree it's complex, but necessary for a utility like this if you want correctness for arbitrary N args

[slaymaker1907]

The alternative is like 20 different type overloads and even then, it wouldn't be fully general.