Live data from Hacker News

TypeScript please give us reflection/runtime types

github.com

201–210 of 287 posts

Re: TypeScript please give us reflection/runtime types

#201

Earlier quoted context omitted.

The author explicitly calls out the existence of all of these tools as being the problem. They seem to want a canonical version that TypeScript itself officially supports.

Situation: There are 14 competing type representation formats TypeScript: We can write our own type file format! Situation: There are 15 competing type representation formats

If typescript itself defines a format, it's hard to imagine that the majority of people won't switch to it.

Though while there's a lot of type-data tools, are there actually a lot of type-data formats out there right now? I've been using zod, and it doesn't have one. You have to use code to tell it about a type. Someone did make a library to let zod load types from pure data, but the format used there is... typescript source code.

Re: TypeScript please give us reflection/runtime types

#202
post #152

Earlier quoted context omitted.

Maybe official preprocessor plugins for TypeScript compiler could help? I understand that everybody who needs it can already put their own preprocessor that generates runtime objects from type information before the code is passed to tsc for compilation. But the effort is inconsistent and distributed. If TypeScript officially supported pluggable preprocessor and plugin ecosystem for it some good solutions might get d…

What's next? An official TypeScript UI framework, will it be Vue, React, Next.js or Svelte? An official TypeScript date library?

I'll take an official WYSIWYG editor while we're at it

Re: TypeScript please give us reflection/runtime types

#204

Earlier quoted context omitted.

What if this macro could be expanded into valid typescript by preprocessor that runs before typescript compiler?

That's an option, and maybe even the ideal one: an extension which takes a TypeScript+macros file and converts it into TypeScript before feeding to the TypeScript compiler. However, such a preprocessor will basically need to re-implement TypeScript's type checking. So either TypeScript must expose it via an API, or the preprocessor needs to itself implement a subset (which as mentioned, could also be faster)

This already exists. One example posted elsewhere in these comments is tst-reflect[1], with which you can write this:

    const fooType = getType();
Which is exactly what you wanted, just as a plugin to TypeScript rather than built into the official compiler.

[1]: https://www.npmjs.com/package/tst-reflect

Re: TypeScript please give us reflection/runtime types

#205

Earlier quoted context omitted.

Nit: they're not asking for runtime type safety; they're asking for the ability to reflect on types (at compile time, to generate values) so that they can use type information at runtime. This helps ensure runtime type safety because (for example) it would be great to have a generic "validation" function that takes an arbitrary interface and an arbitrary object and validates that object. One way to implement this wou…

Here's the thing though: if you wrote your TS properly, you don't need this and asking for it just highlights that you're not using TS the way it's meant to be used. The only place you need runtime type enforcement (when you're writing your own code in TS) is for validating third party data at the point where you're ingesting it into your own code. Once it's in there, it is type safe if you used TS to compile your co…

> And we already have runtime validation libraries to cover that validation step.

Right, but now my type information for inbound data must be in two places: the typescript type, and the validation schema. And heaven forbid I make a mistake and those two become out of sync.

Yes, I can use something like zod to define a schema then infer the type from it, but those inferred types are often … suboptimal to work with.

Re: TypeScript please give us reflection/runtime types

#207

Instead of pleading to the TypeScript gods, why not make a deal with the JavaScript deities? Let's get type-checking into JS! If I want runtime types, I reach for type guards. If I need to do this a lot, then I reach for io-ts or zod and pretty much exclusively write types as validators/codecs/schemas or what-have-you. I don't think TS - as a specification, type-checker, community, or otherwise - needs to concern its…

I have huge doubts whether I'd like JS to have it really. I feel like Promises, decorators and the new pipe operator all went into the wrong directions with their implementations.

How do you feel like promises went in the wrong direction?

(I'd also add modules to your list fwiw, they were designed without taking performance into account.)

Re: TypeScript please give us reflection/runtime types

#209

Earlier quoted context omitted.

[flagged]

I'm here and I have no idea what you're talking about with ESM imports. Please log a bug.

https://github.com/microsoft/TypeScript/issues/54163#issueco...

>Hundreds of Github comments have been rehashed on this issue over and over again. Import paths are not modified during compilation, and we're not going to modify them during compilation, and it isn't because we haven't thought about it before and just need to spend another hundred comments arguing about it.

>The general tenor of discussion here is not great and I don't think this is likely to lead to any further productive discussion, so I'm just going to lock this.

I'm talking about this thing, apologies if I haven't referred to it precisely enough haha. So is it still "no idea", or is it actually "let's pretend we don't hear him, maybe he'll go away" (because you're understandably fed up with answering the same question many times)?

---

Listen, how about I just tell you why I'm asking you all those weird little questions. I still want to hear how you feel about being called a "god among mortals" for writing JavaScript for Microsoft, but I mean c'mon. You're a busy man, you just wondered "what's the ploy here" for a sec and decided it's safest not to bother answering them, right?

I understand that you, like any software engineer, like to work on impactful and meaningful things, and consequently take a measure of pride in your work; so could I, for a certain project, had I not allowed myself to be pressured into building it in TS - by people with no skin in the game, only the current majority consensus on their side ("all JS bad, but TS least bad").

Let's summarize the original post:

- Someone humiliates themselves, literally begging to be heard out.

- They bring forth a huge list of things that, beyond reasonable doubt, prove that their concern is valid.

- They are pointedly ignored, or rebuffed with some form of "I don't know what you are talking about" or "seems like a you problem".

Seeing this dynamic begin to play out in a feature request (out-of-left-field as the whole thing may be), well, that struck a fucking nerve, let me tell you. This has been my exact experience with TS (and no other programming language), when trying to address matters including, but not limited to:

- Whether to use TS at all (which I shouldn't have conceded to in the first place.)

- Whether TS can be adopted gradually (in my case it took multiple rewrites.)

- Whether I'm just imagining that I'm not gaining much by using TS (I'm not.)

- Whether I'm just imagining that I'm experiencing drawbacks from using TS (I did.)

- Whether TS is "just JS with types" (which is about as true as C++ being "just C with classes".)

- Whether the help implicitly offered, conditional on me using TS because "that's what everyone uses now", will ever materialize (which it didn't.)

- Whether I was using TS of my own free will (which is only true insofar as I rose to the challenge of accomodating others' supposed "discomfort" with good ol' JS, at my own expense.)

Every time I raised any of those questions, I was faced with gaslighting. And yes, in the end I did fall as low as begging my teammates for their help - after all, didn't I just rewrite working JS into nearly-working TS so that it would be more accessible to others?

Unrelated subsequent experiences taught me that the (former) coworkers in question might have been just as lost with TS, and even more lost with the JS ecosystem in general (whereas I feel mostly at home with it, coming from Python), but they were reluctant to take accountability and hence admit vulnerability. (Guess adding type annotations doesn't necessarily make code easier to comprehend or maintain, whether you come from a real dynamic language or a real static language, huh.) Well, whatever, that one's on them. And now it's on me to speak out against such insanity as enabled by your product.

When I see someone publicly putting themselves through the same situation (or "pretending" to - what's the difference when everyone is on so many layers of irony that it's not even funny anymore?), and it's not Clojure or Rust or Zig or Nim or Julia -- or JavaScript -- but fucking TypeScript once again; and it's not even their coworkers that they're addressing in this manner, ridiculous in its sheer desperation, but they're talking to the fucking upstream, then I'm not going to be a "good sport"; for me, this rapidly turns from "some stupid thing someone wrote on the Internet" into a matter of professional conscience.

Why did OP have to communicate in this acutely self-deprecatory manner? Is it perhaps because of a systemic issue in how the TS project handles feedback? Having personally experienced the exact same dynamic when discussing TypeScript, it seems such toxic communication has "trickled down" from upstream to us "cowering meek masses", i.e. the developers of Web-based software, i.e. the people who really should know better, because so much of what we build is intended to be directly consumed by other human beings.

For me, this is because TypeScript is not honest open source software. Say it for all to hear: am I wrong that the direction of TypeScript's development is determined by Microsoft's interests first, and the interests of the community a distant second? And is it not misleading and abusive in the slightest to have people learn "Microsoft-flavored JavaScript" instead of the real JavaScript that their browsers can execute, and pretend it's optional when practice shows it's anything but?

The stock phrase "incredibly privileged" makes me sick, but in this case you, Ryan, may truly not believe how privileged your position is in comparison to downstream developers around the entire globe. You're not the end-of-line code-monkey just trying to give the non-technicals some buttons they could click; you and your team are literally imposing your wills on a pre-existing community of fellow programmers, leveraging the unlikely synergy of Microsoft's marketing machine and the open source community's network effects.

On Monday, you will keep moving TypeScript onward; freely benefitting from the community's input on how to do what you're already doing, only better - more efficiently, more correctly. And just as freely ignoring the community's input on whether you're doing the right thing in the first place.

Meanwhile I'll still be recovering from the way your technology ended up impacting my life, no exaggeration, let's not even go there. If even 1% of TS users have been through a similar wringer as myself, that makes for how many people hobbled by your work? Calculate, and consider.

All the best.

Re: TypeScript please give us reflection/runtime types

#210
post #43

I had to read their problem statement like 4 times to understand what they are asking for. This is exactly why simple, concise writing is essential, and their wall of text is...not it. > I love you. You do amazing work. You are gods among mortals. You have brought JavaScript from the darkness, and given it the warm light of strong typing. Look upon us, the cowering meek masses, and understand that we live in the muck…

Counter to this post, as soon as I read the title I knew what this was, & I knew it was speaking exactly to something we've wanted for a long time. This is asking for more official & better supported https://github.com/rbuckton/reflect-metadata . TypeScript is a compiler. It has a lot of type information during compilation. We could write that type information out into a file. Instead what we do is throw that informa…

Why not keep the package separate? I also thought of reflect-metadata separately, and it doesn't hurt to allow users to install plugins to augment core compiler behavior.

Some people have very tight constraints for payload size, and types could blow up payloads

Post reply on HN