-
perry
A native TypeScript compiler written in Rust. Compiles TypeScript directly to executables using SWC and LLVM.
The GitHub page seems to cautiously only mention "no external runtime dependencies", and even has a table comparing the different variants.
https://github.com/PerryTS/perry#binary-size
Seems at least the landing page is heavily vibe coded and copy sounds LLM-generated too. So that's probably where the wrongly used language comes from.
Since the repo has a Claude skills folder, I guess the project itself is partly vibe-coded, too, then?
It's also at 0.x so I'd be interested in how stable it is!
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
> such as this project which is converting tsgo to Rust
If you'd like to follow, here's my attempt at converting tsgo to typescript (called tsts [1]). Admittedly there's AI involved, but it's a very mechanical job. Going from golang to ts is not a very difficult problem, the other way around would have been way harder. The plan is to then compile tsts to binary via tsonic.
[1]: https://github.com/tsoniclang/tsts
-
> strict, deterministic subset of TypeScript
I'll add that page, thanks. Today, almost all of idiomatic TS is supported including most of its utility classes. Dynamic JS-style code is not supported, for example adding a function or a field into an object, prototype-based class modifications etc. I'll compile a list.
> Also, what's an "ambient surface" in this context?
I need to clean up the docs before v1. But the idea is that when JS gets transpiled into C# (or Rust, upcoming), JS globals and built-ins are invalid. The native "surface" is C#, meaning the string is .Net's string type and the methods that you expect on JS strings would be missing. But when you opt in to a surface, such as the "JS surface", the compiler applies surface defined translations such as substring becoming SubString, either directly or via a companion helper class. This allows you to write against standard JS and Node APIs, instead of relying on the stdlib/builtins of the target framework (currently only CLR).
For example, all the projects you see under this use the JS surface: https://github.com/tsoniclang/proof-is-in-the-pudding/tree/m...
-
'curl -s -X POST "https://github.com/login/oauth/access_token" -H "Accept: application/json" -d "client_id=' + GITHUB_CLIENT_ID + '&client_secret=' + GITHUB_CLIENT_SECRET + '&code=' + code + '"'
-
I am taking this attitude to an extreme with tsz. I don't want to announce to the world that tsz is ready until I tested it really really well.
Currently tsz passes nearly 100% of TypeScript tests but that is not enough. I want it to be able to type check complex things like type-challenges solutions or complex utility type packages. I'm stress testing it with a repo with 1.5 million lines of code.
I'm constantly assigning AI agents tasks to find bugs in tsz and open issues.
I'll say this is "alpha" when it can do all those things plus matching tsc exactly in thousands of open source projects where tsc reported type errors. It's easy to find CI runs that tsc reported errors. I'll build a database of all the cases I've verified and will publish those.
For now, tsz is just a work in progress.
https://tsz.dev
