ts-sql VS kanel

There is an implementation of SQL that operates on a table shaped type, entirely at type level. For your amusement: https://github.com/codemix/ts-sql

There are a bunch of more practical takes that codegen types from your database and generate types for your queries, eg: https://github.com/adelsz/pgtyped

To me the second approach seems much more pragmatic because you don’t need to run a SQL parser in a fairly potato interpreter on every build

> If I would level criticisms at dialyzer it would be its sometimes difficult to read warnings, it’s speed (despite being multithreaded) and the race conditions in the VS Code plugin (which is looking for extra maintainers – if I had time I would help).

One of the advantages of TypeScript is that VSCode is written in TypeScript, and both VSCode and TypeScript are developed by the same company, so there's a really nice synergy there. I imagine Kotlin users feel the same way using Jetbrains products, and Swift users feel the same way about XCode.

Dialyzer looks interesting, but I can't imagine giving up on the expressiveness of TypeScript. Some of the things you can do with generics, mapped types, intersection types, template literal types, conditional types, and utility types are almost mind boggling. It's difficult to reap all of the benefits of static analysis without some of these advanced type operators. The type manipulation section of the TS manual is really underrated.

Someone for example wrote an SQL parser in TypeScript that requires no runtime code [1]. It can infer the types of an SQL query's result based on an SQL string without any runtime code execution. There was a similar project where someone built a JSON parser entirely using the type system [2]. There's also an ongoing discussion on Github about the the fact that TypeScript's type system appears to be a Turing-complete language with some other cool examples [3]. My point is that the type system is incredibly expressive. You rarely run into an idiom that can't be typed effectively.

[1] https://github.com/codemix/ts-sql

[2] https://twitter.com/buildsghost/status/1301976526603206657

[3] https://github.com/microsoft/TypeScript/issues/14833

If anyone saw this meme and thought, "damn parsing a type from a SQL query, that looks useful" (as I did), the source appears to be from here.

I mean, why stop there? https://github.com/codemix/ts-sql

Which allows for things like this type that implements a simplified SQL query parser checked against a provided 'database' object:

https://github.com/codemix/ts-sql

This project was my go-to "nifty but pointless" example for TS string literal types before this article :)

author of ts-sql[0] here, this looks great (and a way more practical approach!)

[0] https://github.com/codemix/ts-sql

I'll just quickly plug Kanel (https://github.com/kristiandupont/kanel) which I use to generate Typescript types from a Postgres database. I agree with the author to think migrations-first, though I prefer to write them in SQL to ensure I can utilize all the powerful features that Postgres has to offer.

With it, I only get types for the tables and views etc., so any join will be untyped if done client-side. This is still a big win in my opinion, and I much prefer it to normal ORM's.

I made a tool that generates Typescript types out of a live Postgres database. I've had a request for Kysely support (https://github.com/kristiandupont/kanel/issues/273), but I more or less forgot about it. I would love to hear if that would be helpful.

There are tools that will generate typescript types from a database. I made one for Postgres. But it also works at "compile time", i.e. it doesn't look at a live database. I am not sure if that is what you are asking?

That's interesting. I use Knex a lot and I agree that it's very easy to end up just writing what is basically an ORM on the spot. I haven't quite decided if I think it's a real problem though.

I created and use Kanel (https://github.com/kristiandupont/kanel) to generate Typescript types from my Postgres database which helps a lot. Knex itself has some attempt at type safety but it gets confused quite quickly, so that's where it's tempting to override things.

Interesting. Someone asked me if I supported it in Kanel. At the time it was hard to extend Kanel and then I just forgot but perhaps I should take another look at it. I am not exactly overwhelmed with the types that Knex offers even though it does make an honest attempt.

I have so far found: - kanel https://github.com/kristiandupont/kanel - and pg-to-ts https://github.com/danvk/pg-to-ts

I’ve written before about the way I let the Postgres schema act as the source of truth by generating types with Kanel (assisted by Schemalint). In addition to this, I mention a homemade framework that sort of resembles a server-side Redux. This gives me typesafe database queries that are automatically reflected all the way to the frontend. I am frequently asked to make it open source and that is still the plan. I just need to untangle it from the Submotion source code which just never seems to be high enough priority. I promise I will get around to it :-)

We are using Kanel[1] for this right now — is there an advantage to using this instead?

[1]: https://github.com/kristiandupont/kanel

Sure. I've been using this lib https://github.com/kristiandupont/kanel to get types from my pg database and it makes it a breeze to use raw sql + ts.