Having a type system wasn't really the goal here (there's enough great tools that handle that), but there's plenty of options that could work for you, if you're willing to build it. Some quick ideas:
1. You could add a jsdoc comment per component, let your tool read it and treat it as the source of truth
2. The template is just a js file, so you could parse it, get the params of the fn and try to deduce the types based on the usage
3. You could use typescript and export types
4. Serialize/normalize data before passing to the templating engine
You could get a simple version with little modifications, but it wouldn't really be super useful unless you potentially start adding things like lifecycle events (like mount, unmount), reactivity (state, effects).
Otherwise you might end up reimplementing those.
The intentions of the tool were the server side and static use cases and I didn't plan to use it on the client side.
Correct, that's part of the reason. I've been wanting to move fast without having to worry about the little quirks of different templating languages, frameworks and just get the job done.
I've been using it for small projects and I didn't want to be bothered with all of the setup required to get jsx/tsx transpilation in place.
Another important reason was that I wanted a tool that would let me reach high results in lighthouse, and that's not something you'd get with other tools quickly. Critical css out of the box seemed to be approach that worked for me in this scenario.
It's a restful api that doesn't hold any state, we use jwt (jsonwebtoken) for auth. It's essentially a collection of routers for different actions. Mostly crud, with few exceptions like webhooks, auth flow. We often use middlewares e.g. for things like validation. Everything is written in ts/tsx so the client/server do share types. We serialize data to use it in a standarized/known format in the UI.