Conversation
12e4586 to
2ef3053
Compare
ilbertt
left a comment
There was a problem hiding this comment.
Hey @haydn, thanks for the PR!
I think we should just have one way to type the query to avoid introducing complexity and more documentation. I'm not attached to the current named tag approach, and I really like the zero runtime advantage that your approach would introduce.
What I like about the current named tag approach is that the flow feels more "natural": I assign the name to the query, and the generator picks it up to generate its type. In your approach, the generator creates the type because you referenced it, which feels weird.
Also, I'm a bit scared that we would have to handle many edge cases like type aliases (e.g. import type { Queries as Q }...).
What are your thoughts?
By the way, #40 moved all the advanced cases from the simple (which has also been renamed into "basic" in #42) example to the advanced example, in case you want to update your branch.
Hey @ilbertt. Love the tool. This PR is a bit of an experiment/proposal for an alternative way of discovering the SQL tagged-templates.
The gist of it is this:
IMO, there are two advantages to this approach:
bun-sqlgenwould be a dev-only dependency).sql<Type>`SELECT now()`pattern is better recognised by other tooling (syntax highlighters, formatters, code completions etc).