Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript please give us reflection/runtime types

github.com

Post reply on HN
Print view View original

171–180 of 287 posts

Re: TypeScript please give us reflection/runtime types

#171

Post by hn_throwaway_99 »

paxys wrote: 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…

> This is not possible at all because TypeScript is a compiler. They are really asking for a net new product which has very little to do with the TypeScript that exists today.

That's not correct. All you would really need to do is output type information as JS objects and then support reflection libraries that looked up information at runtime. Two examples where this already happens:

1. TS enums are output as JS objects, as opposed to, for example, string literal union types. That is, "enum Foo { Bar = 'BAR', Baz = 'BAZ }" outputs information that can be queried at runtime, while "type Foo = 'BAR' | 'BAZ'" does not.

2. TS already supports runtime type guards functions, https://www.typescriptlang.org/docs/handbook/2/narrowing.htm.... It wouldn't be hard to generate those functions automatically using information already in the type system.

Re: TypeScript please give us reflection/runtime types

#172

Post by Nullabillity »

paxys wrote: post #125
Nullabillity wrote: post #117

Earlier quoted context omitted.

So now you're stuck writing for an awkward inner platform language rather than using the TS syntax itself.

What's this "awkward inner platform language"? They are asking for a `typescript.generateRuntimeType ()` function to be native to the language. Well plenty of libraries provide exactly this syntax today. Here's tst-reflect: `const type = getType ()`. Notice any difference?

But tst-reflect seems to work by effectively building their own forked tsc compiler.

Re: TypeScript please give us reflection/runtime types

#173

Post by IggleSniggle »

mixedCase wrote: post #167
JulianChastain wrote: post #161

Earlier quoted context omitted.

I would recommend `zod` as a good typescript schema runtime validation library as well. It does require strict type checking to be on however.

Alternatively, io-ts is more performant and has been around for a while longer. Although it does have a more functional interface.

I like typia for doing codegen basically in the way this request is asking: it hooks into the typescript API to create runtypes from plain old typescript

Re: TypeScript please give us reflection/runtime types

#174

Post by dclowd9901 »

paxys wrote: 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…

Yeah, agreed, this ain’t it.

I do think theres room in the world for typescript to be able to emit runtime code from its types, but I don’t think it should be in the business of writing validation libraries.

Closest they should get to this work is writing an interface to export types types into runtime code that another lib can pick up and write validators with.

Re: TypeScript please give us reflection/runtime types

#175

Post by hn_throwaway_99 »

0xb0565e487 wrote: post #153
DanRosenwasser wrote: post #120

Hey all, TypeScript PM here. 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…

I'm relatively new to programming and had a question about TypeScript's functionality. Is there any specific reason why TypeScript doesn't allow for the creation of custom and intricate data types? For example, I'm unable to define a number type within a specific range, or a string that adheres to a certain pattern (like a postal code). I'm imagining a language where I could define a custom data type with a regular f…

> or a string that adheres to a certain pattern (like a postal code).

This is somewhat supported with template literal types, https://www.typescriptlang.org/docs/handbook/2/template-lite.... However, there are good technical/performance reasons they don't support, for example, plain regexes - there is a HUGE discussion on this topic here, https://github.com/microsoft/TypeScript/issues/6579.

Re: TypeScript please give us reflection/runtime types

#176

Post by paxys »

Nullabillity wrote: post #172
paxys wrote: post #125

Earlier quoted context omitted.

What's this "awkward inner platform language"? They are asking for a `typescript.generateRuntimeType ()` function to be native to the language. Well plenty of libraries provide exactly this syntax today. Here's tst-reflect: `const type = getType ()`. Notice any difference?

But tst-reflect seems to work by effectively building their own forked tsc compiler.

No, they have a plugin into the typescript compiler which uses their API. tsc already exposes all of the info they need.

Re: TypeScript please give us reflection/runtime types

#177

Post by wk_end »

0xb0565e487 wrote: post #153
DanRosenwasser wrote: post #120

Hey all, TypeScript PM here. 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…

I'm relatively new to programming and had a question about TypeScript's functionality. Is there any specific reason why TypeScript doesn't allow for the creation of custom and intricate data types? For example, I'm unable to define a number type within a specific range, or a string that adheres to a certain pattern (like a postal code). I'm imagining a language where I could define a custom data type with a regular f…

This is a feature some (experimental) programming languages have - look into dependent types. The long-and-short of it is that it adds a lot of power, but comes at an ergonomic cost - the more your types say about your code, the more the type checker needs to be able to understand and reason about your code, and you start to run up against some fundamental limits of computation unless you start making trade-offs: giving up Turing-completeness, writing proofs for the type checker, stuff like that.

Another interesting point of reference are "refinement types", which allow you to specify things like ranges to "refine" a type; the various constraints are then run through a kind of automated reasoning system called an SMT solver to ensure they're all compatible with each other.

Re: TypeScript please give us reflection/runtime types

#178

Post by crooked-v »

hn_throwaway_99 wrote: post #171
paxys wrote: 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…

> This is not possible at all because TypeScript is a compiler. They are really asking for a net new product which has very little to do with the TypeScript that exists today. That's not correct. All you would really need to do is output type information as JS objects and then support reflection libraries that looked up information at runtime. Two examples where this already happens: 1. TS enums are output as JS obje…

TypeScript enums only exist at all because they were included early on before the project really narrowed on its current goal of being "1-to-1 current JS, but with types". If TypeScript were started from scratch right now with the current philosophy, enums would never exist in the first place.

Re: TypeScript please give us reflection/runtime types

#179

Post by jcparkyn »

RyanCavanaugh wrote: post #109
jxf wrote: post #91

Earlier quoted context omitted.

> This is exactly why simple, concise writing is essential, and their wall of text is...not it. I only skimmed this but felt it was clear. They're asking for TypeScript, as part of the type erasure, to emit the type information it has discovered about the types in a side channel to the emitted JavaScript. Think of, say, PDB files as an analogy. > They are really asking for a net new product which has very little to d…

You can use the TypeScript API to generate this information at whichever level of detail you want. The level of detail TS has about types during the checking phase is much higher than you would want in practice for 99% of projects (e.g. 1 + 2 + 3 has 6 different types associated with it). The level of detail TS has about types during the checking phase is potentially lower than you would want in practice for a lot of…

They're not asking for reflection on _all_ possible types (which would have the problem you mentioned), just ones explicitly requested at compile time via a function call.

Re: TypeScript please give us reflection/runtime types

#180

Post by lolinder »

0xb0565e487 wrote: post #153
DanRosenwasser wrote: post #120

Hey all, TypeScript PM here. 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…

I'm relatively new to programming and had a question about TypeScript's functionality. Is there any specific reason why TypeScript doesn't allow for the creation of custom and intricate data types? For example, I'm unable to define a number type within a specific range, or a string that adheres to a certain pattern (like a postal code). I'm imagining a language where I could define a custom data type with a regular f…

TypeScript actually does have some support for the kinds of types you're suggesting. For example, a US postal code can be defined like so:

    type PostalCode = `${Digit}${Digit}${Digit}${Digit}${Digit}`;

    type Digit = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9';
You could trivially define a `parsePostalCode` function that accepts a string and yields a PostalCode (or throws an error if it's the wrong format).

Ranges like percent are much trickier—TypeScript would need to compute the return type of `Percent + Percent` (0 In most mainstream programming languages the solution to this problem is to define a class that enforces the invariants that you care about—Percent would be a class that defines only the operators you need (do you really need to divide Percent by Percent?) and that throws an exception if it's constructed with an invalid value.

Post reply on HN