implementstion Flexibility, Compiler optimizations, eslint / webpsck / vscode plugins, and more ?!

[bradennapier]

I am copying this over from a question around how we may implement a trpc without monorepo as a requirement (something holding my company back from implementing trpc as well as many others I imagine).

This is more of a collection of concepts which could potentially offer interesting features, use cases, or benefits on top of the current ecosystem.

I am not sure how it may fit into scopes or if they are even good fits... but as I did put together some proof of concepts for Zod for many of these things years ago, I figured I would open a discussion on it.`

@KATT Monorepos ofc agree, that is not always a reality for some. Which makes tRPC a no-brainer for new projects, but to allow adapting to a wider community for those of us where architectures don't support monorepos yet ;-).

This could be implemented with a compiler transformer. Some things to solve ofc... but It is worth pointing out because I have actually built one for zod a couple years ago 🥇 . It was just a Proof of Concept for the zod community, but It would essentially transform a zod input validator into typescript types which could be easily communicated across repo-lines I would imagine.

I can only imagine what capabilities a ts compiler plugin could do for tRPC where essentially every part of the request would be exposed to transform however needed.

• Current thinking would be that it would generate a trpc dependency override similar to how Sequelize and sequelize-typescript currently require you to define manually - but could be automatically built and updated by expanding the right typescript interface.
  • Could be eslint-plugin, IDE Plugin, whateverPack plugin , or others
• Current little proof of concept was very crude and would need a lot of work - but it would be a possibility to make it more universally compatible.
  • Probably some fixes to make it 4.8+ compatible but those are fairly minor if needed.
  • Transformers working in your project can be difficult and requires either patching the ts runtime or using something like ttypescript --
    • This is why I specifically implemented it as a VSCode Extension so it could do it on command for the user rather than needing a transformer plugin or any compile-code setup
    • a client-side eslint plugin may be useable to automatically transform zod inputs copied from the server into typescript types instead that could be ingested or expanded. This can access the ts compiler and is quite straight forward
    • Just a wacky solution and concept :-P but it could potentially work and have a positive result on performance. Obvously quite a lot to make it work though

Shown is Type to Zod but it also did the opposite if I remember (or it'd be easy enough to do if i hadn't implemented that yet lol)

@dohaicuong this would actually probably be similar to how Rust is doing it, as I am sure that does some sort of compiler extension to generate rust code from the AST.