Daniel Beckwith

I'd like to understand a little more about the problem you were having with Vite and exactly why this solves it. Until I understand that problem I'm hesitant to make...

Thanks for the report! Indeed this seems not trivial to fix, but I have some ideas so I'll give it a shot; supporting self-referential types seems like an important feature.

I did start a branch to tackle this back when this issue was opened and made a bit of progress, then forgot about it. I left a bunch of notes...

I took another shot at this and made slightly more progress, but keep finding more and more gnarly problems to work through... The biggest one so far is that any...

Yeah it's tough to figure out the best way to do this. On the one hand, I don't want to have to write `TypeDef` impls for every other library out...

Another thought: you mentioned that the newtype pattern is "cumbersome", and although I think you're not wrong due to the fact that it requires a bit of boilerplate to re-implement...

Maybe I'm missing something, but these bounds seem unnecessary? The `TypeDef` derive macro already adds `TypeDef` bounds to all the generic arguments, and the `Serialize` bound isn't needed for implementing...

Tried it myself, I see the issue, the `Kind::KeyKind` type needs a `TypeDef` bound. Yeah this seems like an analogous problem to what the `bound` option for `serde` is solving....

Actually, this brings up an interesting problem with how associated types are handled. How would you write a Typescript generic type for `ConcreteEntity` that's equivalent to the Rust one? ```typescript...

Hmm, I'm not quite sure how I would even go about doing this. The way this library works is that when you use the `TypeDef` derive macro, it assumes you're...