Ah, amazing project! Congratulations. I was just writing under another thread that we support any and unknowns in two different ways. First, most any and unknowns are lazy programming—if you trace the call graph you can prove they have concrete types, or used only in one shape. If we can't prove a type narrows properly, we lower it to a boxed dynamic value carrier so it doesn't block compilation. Like JSON.parse—for this we have a special syntax, you can do JSON.parse(x) as T, to define the type, and if you don't it becomes a dynamic value whose price you pay only for that site / variable.
We also have limited support for `new Function("...")` via a small evaluator written in C++ that parses and runs the generated body. We mainly built this for Fastify's generated routing functions so it doesn't support classes, asynchronous, destructuring, etc, but conditionals, loops, variable declarations etc work.
There is no "eval" yet, but the same support shape could be added for it too, as the mechanism is already there.
The approaches and the limitations are documented here:
I've been working on this full-time since late 2025. Happy to share what I've learned - feel free to email me as well if you wish to.
> so it doesn't support classes, asynchronous, destructuring
For users, this general category of problems (not knowing these edges) is the hardest. It's amplified if you pull libs from npm. One of the best ways to test compatibility is to test with non-trivial projects, or existing codebases. For example, one which has helped me a lot is trying to compile Microsoft's typescript-go compiler, after translating it from golang to TypeScript via a separately written tool. Large projects surface a ton of issues.
jeswin · · focus · HN ↗
One of the biggest complaints I get is about missing documentation on what TypeScript is not supported.
For example, the following is obviously impossible:
or even: The rest of it is largely doable. But people want to see what's not supported. Otherwise it's not clear to them what to avoid.dashersw · · focus · HN ↗
We also have limited support for `new Function("...")` via a small evaluator written in C++ that parses and runs the generated body. We mainly built this for Fastify's generated routing functions so it doesn't support classes, asynchronous, destructuring, etc, but conditionals, loops, variable declarations etc work.
There is no "eval" yet, but the same support shape could be added for it too, as the mechanism is already there.
The approaches and the limitations are documented here:
<a href="https://github.com/geastack/compiler/blob/main/docs/EVAL.md" rel="nofollow">https://github.com/geastack/compiler/blob/main/docs/EVAL.md <a href="https://github.com/geastack/compiler/blob/main/docs/DYNAMIC-FALLBACK.md" rel="nofollow">https://github.com/geastack/compiler/blob/main/docs/DYNAMIC-...
jeswin · · focus · HN ↗
> so it doesn't support classes, asynchronous, destructuring
For users, this general category of problems (not knowing these edges) is the hardest. It's amplified if you pull libs from npm. One of the best ways to test compatibility is to test with non-trivial projects, or existing codebases. For example, one which has helped me a lot is trying to compile Microsoft's typescript-go compiler, after translating it from golang to TypeScript via a separately written tool. Large projects surface a ton of issues.
dashersw · · focus · HN ↗
And just to clarify, of course, this limitation is only for "eval", not regular TypeScript :)
Most libs from npm compile fine, including Hono, and we are now working on Fastify and MongoDB native driver.
We had an earlier prototype with a full-stack Gea-compiled app with dynamic fallbacks, but I believe we can do better.
And yes, of course, we tried compiling TypeScript compiler to C++ via Gea Stack, but had to deprioritize to get the release out the door.