-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
One Typescript Transformer to run them All #28
Comments
Pinging @JaimeGensler as he may have some insights to share from implementing thyseus-transformer for thyseus. |
Thanks for the ping @endel! Echoing what's said here, a large difficulty in building a TS transformer is finding a way to integrate with folks' bundler/tooling of choice in a way that doesn't require an overwhelming amount of config. I think what would be most helpful - at least in my particular case with Thyseus - is plugins for common bundlers that just accepts other ts transformers as input. For example, for Vite it might look like: import { thyseus } from '@thyseus/typescript-transformer';
import { tsTransformers } from 'some-imaginary-package';
import { defineConfig } from 'vite';
export default defineConfig({
plugins: [tsTransformers(thyseus, /* ... any other transformers */)],
}); Abstracting bundler details behind some shared, easily reuseable interface like this could make authoring and consuming plugins a lot easier. I realize this may not fit the needs of other projects, though - just my experience from Thyseus. |
Another related issue: TypeScript Bytecode Interpreter / Runtime Types Here the developer of Deepkit has already tried to get his solution upstream (by the way, the issue is well worth reading) |
Discussion: One Typescript Transformer to run them All
Hello, I been reading a bit after discovering the typescript-needs-types repo and Looks like the TS team will never emit type data to be used at runtime.
There are currently 2 approaches to solve validation which i suppose is the main use case.
1 - Libraries that that declare an schema and then infer a type from that schema. i.e: zod, valibot, etc...
2 - Libraries that use Typescript Transformers to read the AST and either modify the js output or emit type metadata.
As the TS team would never emit types metadata Think we could identify the libraries that use Typescript Transformers and create a single package that suits every current existing library requirements and use that single one instead duplicated efforts. (Just for the part that parses the AST and eemits code or metadata)
I've personally have investigated two libraries that uses typescript transformers, Typia and Deepkit (from what I can see these two are that mayor players using typescript transformers).
These two as well have different approaches. Typia emmits custom validation functions while Deepkit emits bytecode representing the type metadata.
Maybe we could create a well documented package that boths emits metadata and use a visitor pattern or similar so can emit custom code when traversing the AST, this would cover both typia and deepkit requirement and would be the base for any other project trying to achieve something similar.
We would nne to chat with @samchom and @marcj and check if they are up to the task. I'm not that expert on using the AST but happy to collaborate on what i can 👍
Note I've opened this same Issue in the involved repos:
The text was updated successfully, but these errors were encountered: