Vor ein paar Jahren hatte ich mal ein Experiment. Da habe ich SQL zur Compile-Time über TypeScript-Typen geparst und das Anttwortschema davon abgeleitet. Das lief komplett ohne externes Tooling und geht ohne änderungen am Buildprozess damit auch in JS-Anwendungen. Dadurch hat es auch keinen Runtime-Overhead. Hatte schon ein paar Vorteile. Die Nachteile sind: Das SQL zu parsen ist sehr aufwändig. Alleine das Whitespace-Handling richtig zu machen, ist super schwer. Dazu kommt, dass TS in den Typableitungen eine Begrenzung in der Rekursionstiefe hat. Zwar sind TS-Typen quasi eine funktionale Programmiersprache, aber eine sehr umständliche.
Parallel dazu gab es bei TypeScript immer den Wunsch, sowas wie F# Type-Provider zu bauen. Das hat man ne lange Zeit als Out-Of-Scope angesehen, besonders, wenn da noch Codegen involviert ist.
Jetzt gibt es in TS 7.1 aber etwas, was quasi genau das ist: Content Mappers. Damit kann man für bestimmte Imports definieren, dass ein externes Programm invoked wird, welches dann einen Code zurückgibt, der für Typinferenz verwendet werden kann.
Das hat jetzt der Macher von Zod genommen und etwas für SQL gebaut. Der Vorteil: Das ist auch komplett zur Build-Time. Es verbindet sich auch direkt mit der Datenbank und checkt die Query direkt gegen die native Datenbank, also die Ergebnisse sind garantiert richtig. Auch verschiedene SQL-Dialekte werden damit ordentlich gehandlet. Zwei nachteile: Jede Query muss in eine eigene Datei. Und man kann deshalb auch keine Querys dynamisch zusammenbauen, wie z. B: bei Kysely.