Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I was perfectly satisfied with using https://zod.dev for some runtime validation, and found it really cool that I didn't have to define some nominal type off to the side and could instead just say what I meant inline using a fluent API.
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, encourage programming patterns that do not require run-time metadata.
> 6. Provide additional runtime functionality or libraries. Instead, use TypeScript to describe existing libraries.
[0] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
We have types at home.
My litmus test regarding whether I can even consider using a library in production is: does it have more stars than fartscroll.js?
https://github.com/theonion/fartscroll.js/tree/master
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?
I actually don't know if it's even doable, considering TS's structural type system, where the answer to the question "what type is X?" is not straightforward.
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 information out when the compile ends. Taking all that typing information & throwing it away at the end of compile time is a bad dumb & silly limitation. Especially for a language like JavaScript, which historically could be semi-proud it had such a strong Everything Is An Object philosophy running through it (such as the malleable prototype-based inheritance system); so much type information should be on that Class object. Reflect-metadata for example defined new methods on Reflect to store this metadata.
I could not be more delighted to see the pennon of this website go up. We needed a rallying point for this. We needed a rallying point for keeping class data around. A rallying point for enriching the runtime with good actionable data is a good rallying point.
It's not what's afoot here, but I think you're a bit off-base about the impossibility of adding even some type-safety. We might not be able to get exact TS type safety. But we can definitely build some safety in. Owing to the malleable prototype-based type system in JS, we can add getters/setters to objects to do a lot of type checking. This doesn't even begin to explore the possibility of what we might do with es2015's proxies, which could allow even more interesting checks to be layered in. I also wish JS had an official AST (and renderer), so had more official options for code-rewriting that might let us weave in type checks.
What we can do as programmers is limited by what we have at our disposal. Not throwing out all the typing information, keeping it around at runtime, opens a lot of interesting doors.
Since it's not explicitly listed there, I feel I should shout out David Blass and his incredibly cool ArkType project: https://github.com/arktypeio/arktype
He sometimes (used to?) streams himself working on twitch and it's a really comfy place to hang out: https://www.twitch.tv/arktypeio
Deepkit (listed in the article) is a fascinating project and really deserves to be more popular.
It also demonstrates that what is being asked for is actually practical.
https://deepkit.io/
but you can't have an overload that takes two differently parameterized expressions, this lets you write Java code in a lisp-like syntax that can be metaprogrammed on:
https://github.com/paulhoule/ferocity/blob/main/ferocity-std...
that project got me thinking a lot about the various ways types manifest in Java and I made the discovery that when you add Expression types you practically discover an extended type systems where there are many things that are implied by the existence of ordinary Java types.
Related posts
- TypeScript Essentials: Distinguishing Types with Branding
- Parsing URL Search Parameters with Zod 💎
- Introdução ao TypeScript
- Why doesn't TypeScript properly type Object.keys?
- Why nodejs engineers prefer express over nestjs? although nestjs forces good practice and proper architecture and it seems to be a right choice for complex and enterprise applications like asp.net and Spring. What are the limitations of nestjs compared to express?