The TypeScript language service which powers IDEs and which is maintained/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't exist today given all the listed open source projects, I'm kind of surprised. I don't think the TypeScript team would need to do anything to allow such a project to be developed.
TypeScript please give us reflection/runtime types
81–90 of 287 posts
Re: TypeScript please give us reflection/runtime types
#82> Type erasure is good! It means JavaScript project can consume TypeScript projects without any knowledge of TypeScript. It's just emitted JavaScript. This does not mean you can't emit the type information separately in a consumable lookup table that'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's a second order effect, where the design goal defeats the design goal. :(
I think the author misunderstands the design goals of TypeScript. The goal isn'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. That's the design goal, and that goal is not in conflict with itself.
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.
On the other hand, the convoluted libraries that OP bemoans are perfectly compatible with all of these tools, because they're implemented in user space.
Re: TypeScript please give us reflection/runtime types
#83Please give me an integer type. Just kidding, but I'm not pushing for JavaScript anymore. If rust/WASM works as well, I say go with that.
> Just kidding, but I'm not pushing for JavaScript anymore. If rust/WASM works as well, I say go with that.
This is the direction I'm going. I use rust a LOT these days, and after trying out typescript for a few projects over the course of a few months, I absolutely hate it when comparing it to rust or even any other compiled language. Something about it just rubs me the wrong way...maybe the fact that it has to be JS-compatible, so the type system seems really crude? I can't put my finger on it. It sort of hits this weird inbetween where js is quick to write/prototype and rust is extremely "correct" but the ts type system slows things down/annoys me without providing enough benefits. Also, working with it in nested projects via npm tends to be a huge pain in the ass. Maybe I need to switch to Deno or something so it's native?
Now that rust/wasm is ramping up, I'm considering using rust for the API layer and something like Leptos for the frontend. I've been getting into svelte a lot, and Leptos seems similar enough to not be a huge leap.
Re: TypeScript please give us reflection/runtime types
#84I 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…
> > TypeScript Needs to Emit Runtime Type Information > This is not possible at all because TypeScript is a compiler. Sorry, can you clarify? Many compilers exist in other languages that support RTTI, so it's not clear to me what you mean by this.
There are plenty of projects that do the same for TypeScript (e.g. https://github.com/typescript-rtti/typescript-rtti) and plenty that support some kind of runtime reflection, and overall emitting TS type information at compile time in some readable format is a pretty trivial problem to solve. The complicated part is on the other side – what do you do with this information? How do you get JavaScript engines to understand it?
Re: TypeScript please give us reflection/runtime types
#85I 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…
[deleted]
Re: TypeScript please give us reflection/runtime types
#86The one downside of this proposal is faster typescript processors like esbuild. Right now they don't care about types, they just strip them from the code. It allows them to be very fast and provide fast feedback loop.
With this proposal those tools must become extremely more complicated and probably they will just be as slow as tsc.
Re: TypeScript please give us reflection/runtime types
#87Earlier quoted context omitted.
Why does typescript enum really suck?
There’s a ton written about this if you search for “typescript enums.” I just finished removing them from a major project. Here’s a few of my personal notes: 1. They don’t play well with duck typing. (Eg. show me a subset of an enum) 2. They require an import every time you want to utilize them. 3. They are pretty wordy compared to union strings. 4. Their string value version encourages misuse as a key-value pair. 5.…
Another one: they conflate Type and (Locator) Instance in a unique way that just about nothing else in TS does. Those are two very different things with the same name with Typescript's (antiquated) enums.
There are too many ways to accidentally import/redeclare/rescope the Type of an enum so that TS "knows" the Type, but because that type (generally) has the same "name" as the most likely (Locator) Instance it assumes the same access applies leaving runtime errors behind when that Instance isn't actually imported/available. Typescript has no easy way to tell the difference between access to the Type isn't access to the (Locator) Instance (nor vice versa). Reasoning about those runtime errors or preventing them is additionally tough for people too because of the same "name" problem for two different things.
This is something that's painfully hard to avoid in cases where you are trying to encapsulate an API's Types separate from its imports/exports because they might be introduced or manipulated at runtime (plugins, sandboxes, proxies, etc). Unfortunately, this is also too easy to accidentally do even when you aren't intentionally doing something complicated like that (trying to generate automated .d.ts files in a bundling toolchain, for example, when APIs are in the boundary space between unintentional public API and internal tree-shaking or optimized symbol renaming).
Re: TypeScript please give us reflection/runtime types
#88The TypeScript language service which powers IDEs and which is maintained/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 functi…
It has quite an awkward way of being distributed. If you google for standalone TypeScript language services you'll find unofficial ones. Deno's is much simpler. Maybe they should pioneer this.
Edit: Actually this is the first result, I hadn't tried those exact terms. It's a bit hairy though, which is why the unofficial typescript-language-server npm package wraps it. https://github.com/microsoft/TypeScript/wiki/Standalone-Serv...
Re: TypeScript please give us reflection/runtime types
#89Earlier quoted context omitted.
Emitting types would run counter to several of TypeScript's Design Goals [0]. In particular, it would violate: > 3. Impose no runtime overhead on emitted programs. > 9. Use a consistent, fully erasable, structural type system. It's also explicitly called out as a non-goal in that doc: > 5. Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, en…
If some design goals are stupid they must be changed. It's not god word. It's human word. And this human was wrong.
This isn't just some of the design goals, type erasure is the fundamental guiding principle of TypeScript that allowed it to become successful. Throwing it away because it complicates certain programming patterns should not be done lightly.
Re: TypeScript please give us reflection/runtime types
#90There 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. There are many languages that compile to JavaScript. Pick one of them and use it! And I have the feeling, that people who want runtime typed Typescript would rather like to write Java/OOP style code instead of J…
TypeScript is not JavaScript with type annotations. One of the modes, may be. TypeScript supports emitting old JS constructions which look nothing like original typescript code. So it's more like type annotations + babel. Adding one more thing to this set. Extremely useful thing. I think it's a good idea. I miss it. It's crazy that I can't JSON.parse string into typed structure safely. Every other language can do tha…
No, this is not crazy, this is the design goal of TypeScript.
If you want a statically and runtime typed language in the browser, you should not use typescript. Use Kotlin, Rescript, …