ts-simple-type
transmission-material-ui
ts-simple-type | transmission-material-ui | |
---|---|---|
3 | 1 | |
35 | 0 | |
- | - | |
0.0 | 3.5 | |
about 1 year ago | 6 days ago | |
TypeScript | TypeScript | |
MIT License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ts-simple-type
-
tRPC – Move Fast and Break Nothing. End-to-end typesafe APIs made easy
We use an internal validator library that we infer request types from. It’s similar to Zod (but also predates it by a year).
I’ve also spent some time on a Typescript type to X compiler. My first prototype is open source and targets Thrift, Proto3, Python, and JSON schema: https://github.com/justjake/ts-simple-type/tree/main/src/com...
I’m not happy with the design decision in that codebase to try to “simplify” Typescript types before compiling, and probably won’t continue that implementation, but we have a few internal code generators that consume TS types and output test data builders and model clases we use in production.
- Ezno
-
Ultra-minimal JSON schemas with TypeScript inference
After some frustration with the TypeScript schema library ecosystem, I've decided that I'd prefer to declare my types using TypeScript's excellent type syntax, so I can take advantage of generics, mapped types, etc. Then, I'll take those TypeScript types and compile them to whatever alternative schema format I need.
There are many libraries that claim to convert your Typescript types to other formats, such as ts-json-schema-generator, ts-to-zod, or typeconv/core-types-ts. These libraries work by interpreting the Typescript AST, essentially re-implementing a bare-bones type system from scratch. Most do not support advanced Typescript features like generic application, mapped types, or string literal types. So, what's the point? To avoid those limitations, I use Typescript's first-party ts.TypeChecker API to analyze types, and an existing library called ts-simple-type (which I've forked) to convert from ts.Type to a more usable intermediate format. Then, I recurse over the intermediate format and emit "AST nodes". It's pretty simple, but seems promising.
So far, I have compilers from TypeScript type to Python 3 and Thrift. But I plan to add OpenAPI/JSONSchema, Protobuf (Proto3), Kotlin, Swift, and maybe Zod and Avro. Each target language is around ~300 LoC so they're pretty easy to put together.
Repo: https://github.com/justjake/ts-simple-type
Compiler input and output: https://github.com/justjake/ts-simple-type/blob/jake--compil...
Thrift compiler: https://github.com/justjake/ts-simple-type/blob/jake--compil...
Python compiler: https://github.com/justjake/ts-simple-type/blob/jake--compil...
transmission-material-ui
What are some alternatives?
fern-java - Generate Java models, clients, and server interfaces from your API definition.
electron-trpc - Build type-safe Electron inter-process communication using tRPC
telefunc - Remote Functions. Instead of API.
ts-websocket-compressor - This library compresses data sent over a WebSocket connection to improve throughput on devices that can't use compression for one reason or another.
ts-to-zod - Generate zod schemas from typescript types/interfaces
stytch-t3-example - An example app demonstrating how to use Stytch within the T3 stack
oto - Go driven rpc code generation tool for right now.
vellum-client-python - Python SDK for Vellum API
sdk-node - Node.js SDK for the Squidex API
vellum-client-generator - Vellum’s Fern API which is used to generate SDKs.