TypeScript please give us reflection/runtime types

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.<p>&gt; 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 and mire of a world where we are doomed to endlessly crawl on our bellies through the alleys of Github seeking the one true npm. We will forever wonder in the dark, until we have a type reflection model.<p>What even are they getting at?<p>As for their actual ask (runtime type safety), it is probably not going to happen because the TypeScript project has drawn the line at not being an alternate or additive runtime for JavaScript. Their job is simply to compile down to JS code and exit the picture. Whatever happens after that (in V8 or elsewhere) is your own business.<p>&gt; TypeScript Needs to Emit Runtime Type Information<p>This is not possible at all because TypeScript is a <i>compiler</i>. They are really asking for a net new product which has very little to do with the TypeScript that exists today.

Hey all, TypeScript PM here.<p>I understand the desire here. Runtime type checking is often necessary for data validation, and we can see lots of libraries developed to help fill the gap here. But I think the fact that there are so many libraries with different design decisions is pretty indicative that this is not a solved problem with an obvious solution. We knew this going into the early design of TypeScript, and it&#x27;s a principle that&#x27;s held up very well.<p>What have been happy to find is that we&#x27;ve grown TypeScript to be powerful enough to communicate precisely what runtime type-checking libraries are actually doing, so that we can derive the types directly. The dual of this is that people have the tools they need to build up runtime type validation logic out of types by using our APIs. That feels like a reasonable level of flexibility.

There is a good reason for not doing this. Typescript would become some kind of runtime on top of JavaScript. A new language that compiles to JavaScript. Currently TS is only JavaScript with type annotations.<p>There are many languages that compile to JavaScript. Pick one of them and use it!<p>And I have the feeling, that people who want runtime typed Typescript would rather like to write Java&#x2F;OOP style code instead of JavaScript. But JavaScript is a dynamically typed language, and that&#x27;s also nice. Be happy with what you have!

Above all of what I write below, I think that this is a very valid issue for discussion and debate. I don&#x27;t think there&#x27;s one objective correct answer. So this isn&#x27;t me dictating what TypeScript shalt be.<p>TypeScript is an entirely optional layer on top of JavaScript, with the exception of `Enum` that emits an object, many of which see as a mistake. You don&#x27;t even have to &quot;transform&quot; TS code to get JS: you just have to delete the typings. The rest is just JS.<p>Unless you want to depart heavily from this principle, which I think is crucially important so long as there&#x27;s still human-maintained JS code out there, what I think they&#x27;re asking for is a library to take the types and write serializers&#x2F;validators for. Which there are many of. So I think the real request is to make the one canonical choice out of a field of many choices, which I also agree with the spirit of. But is that really in scope for the TypeScript project?<p>What I personally don&#x27;t want is runtime reflection for TypeScript. Or at least, not a core part of the language. Because I like that TypeScript is just for compilation and at runtime you just have JavaScript, without any sort of abstraction layer that turns JS into some sort of intermediate representation with overhead or more indirection for debugging. I <i>cherish</i> the fact that even without source mappings, my output JS is perfectly legible and debuggable.

Instead of pleading to the TypeScript gods, why not make a deal with the JavaScript deities? Let&#x27;s get type-checking into JS!<p>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&#x2F;codecs&#x2F;schemas or what-have-you.<p>I don&#x27;t think TS - as a specification, type-checker, community, or otherwise - needs to concern itself with runtime validation UNLESS JS gets some agreed upon way to do it.

I vaguely remember one of typescripts developers stating that if they had to start it all over again, enums would not be added; as enums are the only thing emitting runtime code.<p>Typescript does not change runtime behaviour, there is no special typescript {#if}

Better title: TypeScript please give us reflection&#x2F;runtime types<p>AFAIK the best current solution is emitlDecoratorMetadata. [1]<p>[1] <a href="https:&#x2F;&#x2F;www.typescriptlang.org&#x2F;tsconfig#emitDecoratorMetadata" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.typescriptlang.org&#x2F;tsconfig#emitDecoratorMetadat...</a>

&gt; Type erasure is good! It means JavaScript project can consume TypeScript projects without any knowledge of TypeScript. It&#x27;s just emitted JavaScript. This does not mean you can&#x27;t emit the type information separately in a consumable lookup table that&#x27;s separate from the code. The lack of this type information means we use esoteric libraries which ultimately pollute the JavaScript with all the convoluted typing working arounds... soo... type erasure has defeated the purpose of type erasure. It&#x27;s a second order effect, where the design goal defeats the design goal. :(<p>I think the author misunderstands the design goals of TypeScript. The goal isn&#x27;t to have pristine, beautiful JS code with no complexity, the goal is to have the runtime semantics of TypeScript be identical to the runtime semantics of JavaScript. Barring the regretted exception of enums, TypeScript can be converted to JavaScript by simply stripping type annotations. <i>That&#x27;s</i> the design goal, and that goal is not in conflict with itself.<p>The ecosystem that has built up around TypeScript depends on complete type erasure, and much of it would evaporate if this wish were granted. TS support in ESBuild, Deno, and Bun would become nearly impossible, because each would need to re-implement all of tsc in their respective languages, while right now they just need to maintain their own simplified parsers.<p>On the other hand, the convoluted libraries that OP bemoans are perfectly compatible with all of these tools, because they&#x27;re implemented in user space.

Thanks for this. I thought I was screaming into a void. I started with typescript in 2018 and after two years started to believe this is just not really a solution because what it is. I came from Haskell&#x2F;c#&#x2F;f#, and TS, while it has a very powerful type system, just doesn’t give you much of the advantages the above languages give you outside (some of) dev. Even when it does, it is really limited in practice (aka when dealing with the real world) vs, let’s say, c#. You can defend from that somewhat, however, you have to always keep the extremely (and that’s intended, but not what it could be) leaky abstractions in mind to not run into bugs that shouldn’t be possible in something that claims static typing (if you don’t know that it drops to js without checks after compile).

I was perfectly satisfied with using <a href="https:&#x2F;&#x2F;zod.dev" rel="nofollow noreferrer">https:&#x2F;&#x2F;zod.dev</a> for some runtime data validation, and found it really cool that I didn&#x27;t have to define some nominal type off to the side and could instead just say what I meant inline using a fluent API.

I’m mainly a backend programmer, so I know just a little typescript, but I don’t really understand what they’re asking for here. It sounds like they want to serialize and deserialize typescript types automatically? If so, that sounds like a good fit for a library, not something most languages offer. (Please educate me if I’m missing the point)

Very interesting post to me. There always was the argument that TS should be erasable and carry no runtime information, enums and decorators are a mistake, etc.<p>For what it&#x27;s worth, I want my production bundle to be as small as possible. Most people use bundlers among TypeScript, which further complicates things.<p>I would love a <i>standard</i> library to e.g. generate type predicate functions from TS types.<p>Taming the beast from this end might even end up useful for things like compilers, no?<p>TS provides a nice mechanism to be strict in the frontend and validate types using runtime code, that is, type predicates.<p>But from a higher level, this has never been enough, and you want to map JSON to TS types using some kind of schema definition.<p>I would love to just be able to pass in a TypeScript type and generate its type predicate at compile time.<p>Unfortunately, this is impossible due to the halting problem.<p>So, a <i>standard</i> solution for the case of a plain serializable JS&#x2F;JSON object and the according TS interface would be very much welcome.<p>Edit: and all of this is of course about data from external sources (requests, DOM, compiler...). For all of the code and data known at compile time, there is rarely a need to validate types, as they are statically analyzable.<p>So there is a huge scope that TypeScript has to cater to. It includes JS projects where external type definitions often become obsolete and people who code in TS but do not enable strict mode for their own code (that is, disallow &quot;any&quot;). And all of these type defintions have to be interoperable.<p>For API requests, this is basically calling for a default generic REST client, and I agree that would be useful. The REST client could use type predicate functions extensively.

I dunno, this seems like it would be out of scope for something like TS proper (there&#x27;s already been a ton of feature creep, anyway). Reflection is generally implemented via runtimes, which can be very clunky. Is it really worth doing this in JS? Tooling already seems too bulky as is.

This shouldn&#x27;t happen... unless someone finds a way to do this without a runtime overhead, which naturally seems impossible.<p>If this is done, TS will become something entirely different as it currently doesn&#x27;t have a runtime: it&#x27;s a huge-and-smart linter.<p>But that&#x27;s all about it. No matter how huge, it&#x27;s a linter.<p>Reflection would imply something beyond that. Even though I absolutely love reflection, I believe it should not be integrated into TS.

The one downside of this proposal is faster typescript processors like esbuild. Right now they don&#x27;t care about types, they just strip them from the code. It allows them to be very fast and provide fast feedback loop.<p>With this proposal those tools must become extremely more complicated and probably they will just be as slow as tsc.

Modern TS code is hard for me to read and reason, and I use Rust, Haskell, C++. Way too complex for my brain

There are good typed deserialization libraries. Personally, I prefer runtypes but there are options.

As listed, Typebox is excellent for this use case - it correctly implements the JSON schema spec and allows you to use it to write OpenAPI specifications. At my company we use this to write type-safe handlers &amp; generate our API documentation!

OP and those who feel a similar sentiment should give C# a shot, it&#x27;s what they want regardless of whether they know it or not.

Please give me an integer type.<p>Just kidding, but I&#x27;m not pushing for JavaScript anymore. If rust&#x2F;WASM works as well, I say go with that.

If anything, the wide range of different approaches to run-time type information listed here is pretty good evidence that there are many different use cases and any approach built in to TS would not cover them all.

This is the perennial problem with language design. Everyone wants something and they even have reasonable grounds to ask for it.<p>I myself have come across moments where some rtti&#x2F;reflection would have been useful. In those cases I was often able to use branded types. Having something like that built into the language might be nice. But I&#x27;d also support TypeScript and JavaScript developers making the choice not to support it ever. IME, working around rtti type code often forces the programmer to come up with a much better approach.

Fairly recently I built a C library for object serialization, based on run-time reflection. Run-time reflection is not necessary to the task and makes it perform worse than a code-generating solution.<p>The run-time reflection approach is good in one way: it doesn&#x27;t add tooling to the project. All the modules that use serialization have to make a bunch of tedious API calls to build the type object which represents the C structure. This is created once and stashed in a global variable. Then it is used as a parameter when serializing and deserializing.<p>There is a performance impact because the marshaling code is interpreting the type object; it recursively walks the type object, and in parallel it walks the C object to extract or stuff material.<p>A generative approach would just write a serialization and deserialization stub. There would be no need for any type object to be walked at run-time. No need to construct such objects at startup and no need to carry the library for that.<p>But there would be some tool which itself has to be compiled (for the build machine, not the embedded targets), and then some Makefile steps to run that tool on some interface files. The thought of inflicting that one the project made me go yuck.<p>A third possibility is to have the run-time type info objects, and add JIT. Why do something easy, like a code generation tool called out of Makefile, when you can do something hard and nonportable?

I&#x27;m kind of doubting the real value of this.<p>For validation, ORMs, APIs, etc., once you move beyond the simplest cases, you need more information than is present in Typescript type information. And that&#x27;s before we get to the app-specific concerns.<p>So you&#x27;re going to end up with schemas, boiler-plate, code-generators, and&#x2F;or glue code anyway. Not to mention the libraries to help manage this stuff.<p>It&#x27;s not that it&#x27;s completely unhelpful, but I think it&#x27;s a partial solution, and not the tricky part either.

2¢, having non-runtime types makes code behavior easier to reason about, especially when aggressive type inference is present, and I&#x27;d hate to lose it<p>One of the things I don&#x27;t love about Rust is how type inference affects program behavior in ways that can be really subtle. In Rust&#x27;s case this is a necessary evil because it doesn&#x27;t have a dynamic foundation, but TypeScript has done great without that compromise

Anything run-time has to come from JavaScript.<p>TypeScript is syntactic expansion layer over JavaScript.<p>&quot;C preprocessor, please give me arrays that know how big they are at run-time. Oh, and access to the calling function&#x27;s local variables!&quot;<p>&quot;Common Lisp defmacro, give me continuations usable anywhere!&quot;<p>A macro layer can bring you the pie in the sky, but only (1) at some nonozero cost and (2) with additional representations that are not understood by regular code that is not in that framework.<p>Suppose a TypeScript type object is attached to every run-time object created in TypeScript. Firstly, those objects become more bloated and expensive to construct. [Edit: not really: all objects of the same type can have a pointer to the same meta-data which is created once]. They will need run-time support in their execution environment in order to have those type representations. Objects not created by TypeScript-generated code will not have anything like that attached to them, so places in the system where the two domains interoperate won&#x27;t be able to rely on reflection; it will need a fallback for objects that don&#x27;t do reflection.<p>I think serialization can be done without reflection. Because at the time when the static language is being processed, you could annotate certain types as requiring serialization. Then for those types, TypeScript would generate the marshaling routines.<p>Generating marshaling stubs from an interface language has been done in the C world for decades. It doesn&#x27;t require any run-time types. The generated marshaling stubs just know how to walk objects of the type that they handle, and that&#x27;s it.<p>It looks like in TypeScript, serialization is just punted to JSON, which is inadequate because when we are deserializing, we want to check that the JSON blob has a type and shape compatible with the TypeScript-level type. (Or even for that that type to be inferred in some way.) There are some libraries that try to do something in this direction like ts-serializer.<p>I think it&#x27;s something you really want in TypeScript itself.<p>Basically round up the half-dozen or so use cases for reflection, and provide for all of them somehow without actual reflection. It&#x27;s an X&#x2F;Y problem. People really want to do Y (e.g. serialization), and believe that they must first solve X (have metadata in objects for reflection).

While type hints in Python are not as nice as typescript annotations, I understand their plea, because once thing Python does better is runtime introspection.<p>Which means we can have dataclass, pydantic, typer and fastapi all generating their stuff from regular type hints. No need for special syntax or functions. And that&#x27;s super nice.

A lo of people in this thread seem to be misunderstanding what is being asked for. There is no runtime reflection needed. What is really needed is -<p>1. A way to get a value that represents the <i>type</i> of any statically known type (i.e. known at compile time). 2. A way to compare two typereps for equality. 3. A way to convert between types if the typereps are equal.<p>This is basically the equivalent of the `Typeable` class in Haskell and PureScript (<a href="https:&#x2F;&#x2F;hackage.haskell.org&#x2F;package&#x2F;base&#x2F;docs&#x2F;Data-Typeable.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;hackage.haskell.org&#x2F;package&#x2F;base&#x2F;docs&#x2F;Data-Typeable....</a>). Both Haskell and PureScript erase types at runtime, so it is possible to do without adding a runtime to TypeScript as well.

The TypeScript language service which powers IDEs and which is maintained&#x2F;shipped with TypeScript already has the knowledge of all the types in your application. It seems like it would be relatively straight-forward (though a lot of work!) to develop some sort of code gen library that uses the TypeScript types known to the language service to reflect on those types and emit some sort of runtime type validation functions as part of a build step. This could be done in an npm module similar to webpack or in an IDE plugin. If that functionality doesn&#x27;t exist today given all the listed open source projects, I&#x27;m kind of surprised. I don&#x27;t think the TypeScript team would need to do anything to allow such a project to be developed.

Maybe controversial, but I think code generation is fine. It work well enough in Go or C#.

Normally I&#x27;d say &quot;hard pass.&quot; I&#x27;m pretty comfortable with static types being a model where the compiler throws the type information away at compile time, so I can type with abandon without worrying that I&#x27;m going to impact runtime performance in my generated code.<p>... TypeScript may be one exception to my rule of thumb. It&#x27;s already compiling down to JavaScript, so you&#x27;re already paying a performance tax in having your code run in an interpreted language. The question should be &quot;how much more of a performance tax are you paying annotating things with type runtime metadata?&quot;

We have types at home.<p>My litmus test regarding whether I can even consider using a library in production is: does it have more stars than fartscroll.js?<p><a href="https:&#x2F;&#x2F;github.com&#x2F;theonion&#x2F;fartscroll.js&#x2F;tree&#x2F;master">https:&#x2F;&#x2F;github.com&#x2F;theonion&#x2F;fartscroll.js&#x2F;tree&#x2F;master</a><p>Most of the entries there are below that number, which begs the question: is this really that much of a problem that it mandates the drastic changes required?<p>I actually don&#x27;t know if it&#x27;s even doable, considering TS&#x27;s structural type system, where the answer to the question &quot;what type is X?&quot; is not straightforward.

What I really miss is a way to extract type information directly from the compiler. Ie to have a ‘macro’ that takes a type as an input and returns a readable text or a json structure describing that type<p>It still wouldn’t be runtime typing, the compiler would just insert a constant wherever you use such a macro so I don’t think it would conflict with typescript’s goals. But it would make it a lot easier to build extra checks when deserializing data - or just give richer debug information.<p>But it would probably be hard for eg esbuild to support such a feature if tsc adds it. So I couldn’t use it anyway :)

The problem with TypeScript isn&#x27;t the lack of reflection. The problem is that at runtime its type system is still Javascript in all its glory. Workarounds are just band-aids on the underlying mess at best.

Reflection on a language that compiles to javascript? I don&#x27;t get it. Why are people so allergic to macros?? Every stinking language that has compiled to JS has had a chance to do macros but they don&#x27;t. Coming from many years spent in the lisp world, metaprogramming is this incredible feature that, in my experience, completely negates the need for runtime reflection while adding many other possibilities as well. I get it...the syntax is way harder when your language isn&#x27;t basically a pre-parsed AST. But rust does it.<p>Seems like a huge waste.

Can anyone do a &quot;explain lime I&#x27;m five&quot; summary of the problem and how the solution would work when typescript is converted down to JavaScript again so the interpreter takes it? Looking from the top it seems like it would add more complexity (and potentially new bugs or exceptions) than it could make things faster and safer.<p>IF typescript was 100% its own thing and not built on top of JS, it would make complete sense to do it, but with a js engine below it...

Since it&#x27;s not explicitly listed there, I feel I should shout out David Blass and his incredibly cool ArkType project[1]. It&#x27;s typescript wizardry.<p>He sometimes (used to?) streams himself working on twitch and it&#x27;s a really comfy place to hang out.[2]<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;arktypeio&#x2F;arktype">https:&#x2F;&#x2F;github.com&#x2F;arktypeio&#x2F;arktype</a><p>[2] <a href="https:&#x2F;&#x2F;www.twitch.tv&#x2F;arktypeio" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.twitch.tv&#x2F;arktypeio</a>

Stated differently.<p>Our JavaScript bundles are not large enough or slow enough. Could you please make it so we can ship even more data to the client and add more branching so we can give our customers an even worse experience.<p>You want reflection, use a language that has it and ship webassembly to the client, it will likely be significantly more performant than adding even more bloat to what is already needing to run in the JS interpreter.

This is just the desperation that comes with poor understanding. The strength of a type system should ideally be that you could confidently execute the underlying code even with full type erasure, and while I realize that TS has already sacrificed this to some extent, adding reflection&#x2F;runtime “types” would just further degrade the value of TS.<p>No thanks! If you want this, compile java to JS or something equally hamfisted…

Please no, typescript is already complex as all hell.

This comes up so often, and every time I wonder how much the people who want it have a shared understanding of what it is they want. I realize this is reiterating a point that TS team members have already made, but I’m coming from a different perspective: actually having built higher level tooling on top of one of the solutions mentioned in the post, and having built a fairly mature prototype of another solution from the ground up to address problems none of the existing offerings solve.<p>My use case isn’t particularly outlandish, I can even imagine it being non-niche if I ever get around to publishing it. But it’s also pretty far afield from any of the existing solutions: platform-agnostic documentation as a core&#x2F;foundational principle.<p>My original work implemented JSON Schema documentation on top of io-ts, and added some runtime and type level functionality to support that. But my vision for a hypothetical successor is that<p>- the documentation standard itself (whether JSON Schema, OpenAPI, or any other underlying format) should be the underlying primitive<p>- the underlying format should be composable to produce APIs which are just as user friendly (ie users shouldn’t have to muck around with the doc format unless they have a really specific use case, and even then they should still be able to compose the parts they’re not concerned with)<p>- no additional build time codegen tooling: define a schema once, its type is inferrable from the definition without a compiler extension or IDE config, its documentation is a plain function call executable in any standard runtime to resolve what’s composed<p>This is all very achievable in TypeScript as-is. But it’s way out of scope from what I imagine any first class thing would or should be. And sure, if such first class thing existed, that wouldn’t make my thing any less achievable. But here’s what I think it would do:<p>1. Disincentivize usage by users who prefer the first class thing with type syntax as the primary authoring mechanism.<p>2. Incentivize me to cave on tooling to accommodate that.<p>3. Piss people off because “we wanted less tooling not more”.<p>4. Recurse into this same debate.<p>I’d personally prefer the status quo. Even if that means rehashing the same debate every few months, at least it’s at a recursion depth that’s manageable and doesn’t have countless other sets of unintended consequences.

I&#x27;ve heard the same complaint about Elm

Runtime type checking is an explicit non-goal of TS: <a href="https:&#x2F;&#x2F;www.dsebastien.net&#x2F;2020-04-25-typescript-non-goals&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.dsebastien.net&#x2F;2020-04-25-typescript-non-goals&#x2F;</a>

Deepkit (listed in the article) is a fascinating project and really deserves to be more popular.<p>It also demonstrates that what is being asked for is actually practical.<p><a href="https:&#x2F;&#x2F;deepkit.io&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;deepkit.io&#x2F;</a>

Future ECMAScript iterations will include types and then hopefully TypeScript can take advantage of that to implement reflection and other cool things

Reflection is terrible. The only thing that is worse is creating something like reflection in imperative code in languages that do not have it.

unpopular opinion, but this just fosters my opinion that TS people just don&#x27;t understand JS at all. I wish TS would just die (another currently unpopular opinion). If you want runtime type safety, go use a different language and stop trying to ruin JS, it&#x27;s already the messed up crazy cousin and it doesn&#x27;t need to be in-bread anymore, it&#x27;s perfect the way it is!

So this is asking for a completely different language?

It would be nice but the problem is not that big of a deal if you use any of the community libraries they mentioned.

Typescript already kind of has it, it&#x27;s just they got it backwards.<p>One needs to define their types as a const, like this one:<p>``` [{ type: Number, name: &quot;field1&quot; }, { type: String, name: &quot;field2&quot; }] as const ```<p>and then use Typescript magic to convert it into the fully fledged Typescript type.<p>Yes, it&#x27;s annoying, but it&#x27;s more flexible.

Use zod

I’m not an expert or anything but I sincerely feel like this is barking up the wrong tree.<p>To anyone who works on typescript&#x2F;JavaScript outside the context of a web browser, you DO NOT matter as far as I am concerned. If I was in control of JavaScript&#x2F;typescript, I’d give zero attention to your demands. You are not my top priority. Go away.<p>I feel like we are losing focus here. Should JavaScript be an all purpose language? Yes. Should we focus on making a web browser context, also yes.<p>The reason I led with this is that I think it is up to the JavaScript folks and the web browser vendors to include support for this before typescript can change what it emits. Ideally, I’d say wait a couple of years after browser vendors include support to implement this in typescript.