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

191–200 of 287 posts

Re: TypeScript please give us reflection/runtime types

#191

Post by scotty79 »

andix wrote: post #152
scotty79 wrote: post #135

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?

What's the point of any of those?

Generating code based on type annotations is frequently requested feature directly related to the core feature of TypeScript which is type system.

Re: TypeScript please give us reflection/runtime types

#192

Post by vendiddy »

JulianChastain wrote: post #161
IggleSniggle wrote: post #147

Earlier quoted context omitted.

Just use a run-type transformer like typia, hooked right into typescript-compile. Get your runtime type validators generated from nothing but the typescript definitions. Alternatively, use a runtime validator the provides good type inference out of the box so you're still only declaring your types once.

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

I use zod but it's a workaround. I use non standard syntax to define types.

If typescript emitted type information, we'd be able to automatically get runtime validation at the boundaries of our apps.

Re: TypeScript please give us reflection/runtime types

#193

Post by RussBrown00 »

unpopular opinion, but this just fosters my opinion that TS people just don'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's already the messed up crazy cousin and it doesn't need to be in-bread anymore, it's perfect the way it is!

Re: TypeScript please give us reflection/runtime types

#194

Post by jitl »

pas wrote: post #186
RyanCavanaugh wrote: post #131

Earlier quoted context omitted.

Not to be flip, but if it were really all this easy, we would have done it already. There are dozens of questions you can throw at this code: What if the input's a union? What if it's a nested union -- how do you avoid combinatorial explosion? What if the input is a function -- how do you validate its parameter types using runtime information? What if the input is a conditional type? What if you're inside a generic f…

Maybe I'm very mistaken, but to me it seems this code snippet is basically an alternative to writing a ton of "infer"-s and overloads, no? So the same pattern matching could be used in the "switch". Whatever the complier knows can be locally matched, and the combinations have to be already handled by the developer.

It's hard to come up with a compiler that produces a sound checker for arbitrarily complex union/intersection types. Perhaps there could be a restriction on reflection to "simple enough" types, but that's always going to be a weirdly moving target based on heuristics. There's already cases where Typescript tries to generate ~40MB+ .d.ts files which are just re-stating the types themselves. So it's easy to imagine a validator compiler emitting 100MB+ of code to check more wild and crazy types.

Re: TypeScript please give us reflection/runtime types

#195

Post by Dylan16807 »

paxys wrote: post #176
Nullabillity wrote: post #172

Earlier quoted context omitted.

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.

Okay so it's not a forked compiler but it's adding a feature to the compiler.

At which point it makes a lot of sense to ask why that feature shouldn't be merged.

Re: TypeScript please give us reflection/runtime types

#196

Post by armchairhacker »

scotty79 wrote: post #137
armchairhacker wrote: post #53

Earlier quoted context omitted.

Not necessarily. Consider const fooType = generateTypeInfo! (); Where `generateTypeInfo!` is a macro that expands to a JS object encoding the “Foo” type (e.g. if `Foo` a record type, `fooType` will be a record with its encoded field types). It still compiles to readable JavaScript. What this macro does break is that TS = JavaScript with type annotations, and all you need to do to compile is remove those annotations (…

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)

Re: TypeScript please give us reflection/runtime types

#197

Post by cannabis_sam »

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/runtime “types” would just further degrade the value of TS.

No thanks! If you want this, compile java to JS or something equally hamfisted…

Re: TypeScript please give us reflection/runtime types

#198

Post by jerf »

n2d4 wrote: post #166
0xb0565e487 wrote: post #153

Earlier quoted context omitted.

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…

> Is the lack of such a feature in TypeScript (or any language) a deliberate design decision to avoid unnecessary complexity, or due to technical constraints such as performance considerations? It makes a lot of things impossible. For example, if you defined two different types of ranges, OneToFifty and OneToHundred similarly to your PercentType above, the following code would be problematic: let x: OneToFifty = ; le…

It's the fundamental programming language design conundrum: Every programming language feature looks easy in isolation, but once you start composing it with everything else, they get hard. And hardly anything composes as complexly as programming languages.

There's sort of a meme where you should never ask why someone doesn't "just" do something, and of all the people you shouldn't ask that of, programming language designers are way, way up there. Every feature interacts not just with itself, not just with every other feature in the language, but also in every other possible combination of those features at arbitrary levels of complexity, and you can be assured that someone, somewhere out there is using that exact combination, either deliberately for some purpose, or without even realizing it.

Re: TypeScript please give us reflection/runtime types

#200

Post by chucklenorris »

andix wrote: post #93
vbezhenar wrote: post #79

Earlier quoted context omitted.

If some design goals are stupid they must be changed. It's not god word. It's human word. And this human was wrong.

In my opinion they are not stupid, they make a lot of sense. And many people seem to agree and use typescript. If you don’t agree, use something else. There are many alternatives, pick something that is „smart“ in your opinion.

Unfortunately i can't. Like most of the people here i work in a company, with other people and i can't chose $language that is less dumb for obvious reasons. Typescript IS the only practical solution for web development at scale. I'm stuck with the design philosophy of a guy that's not facing my problems and obviously doesn't care.
Post reply on HN