knex-types VS schemats

GraphQL.js + Knex.js + knex-types (TypeScript generator for Knex)

And in order to have auto-complete and type checking, you can combine it with knex-types.

I generate TypeScript enums and types from the actual database schema using knex-types as part of the yarn db:reset script that used during local development (after making changes to the db schema migration files). See example project.

I tried to take advantage of TypeORM in a couple of projects, but then reverted back to knex + knex-types — just a PostgreSQL client with query builder works great, IMO, especially for GraphQL API development.

Nope. Just plain GraphQL.js + Knex.js (example), often typed manually since it's not where most of the time spend on when building an API server (though it can be automated via a scaffolding script if there are too many db tables). Generating TypeScript definitions off the actual db schema using knex-types (example).

Luckily, there is a solution! Assuming you have a database table that looks like this (Knex migration):

:::note When using remote APIs, we often have the possibility to generate the types automatically from a JSON schema for REST APIs, from protobuf files for gRPC-based APIs, from a database schema, etc. You might even be using an external API through an SDK that already provides you with all types. In such cases, the creation of specialized Error classes is not mandatory. However, it might still be a good idea to do so to provide application-specific errors rather than bubbling up 3rd-party low-level errors. For such cases, the upcoming Ecma TC39 proposal for Error Cause is useful as it allows to chain errors. Polyfills exist: Pony Cause or error-cause. :::

Using a library such as that one https://github.com/SweetIQ/schemats