TypeORM is poorly maintained (the lead author had a breakdown and appears to be inactive, and failed to delegate ownership to others), and is riddled with bad abstractions, poor design choices and an enormous pile of game-breaking bugs that make the TypeScript types unsafe and it’s usage clunky and dangerous. I would absolutely use knex, which works, over TypeORM, which routinely doesn’t.
Interesting -- I actually haven't had as many problems as you have with TypeORM -- it's just mostly worked. Then again, maybe I'm a rare case, because I basically ignore the ORM side and use a little repository pattern, the query builder, and write my own migrations in SQL (as in all the migrations are `await queryRunner.query(...);`).
It's been excellent for me -- I ignore the bad abstractions, have a good underlying database (postgres), and drop down to parametrized raw SQL whenever I need to, it's held up extraordinarily well I think.
Could you expand on some specific issues/frustrations? Just curious about the side I'm clearly not seeing.
And once you're good at SQL, it will never let you down. Query builders + reasonably abstracted libraries for the repetitive things (the repository pattern in TypeORM gets me just about all the CRUD I need), and query building/raw queries for the rest.
The things that the DB can do (I'm thinking about postgres) are amazing, and you just aren't going to get a chance to use a lot of it really from a lowest common denominator ORM. Yeah, you probably don't need it -- but then again why not just use a tool like Postgrest from the start?
Yeah my issues are from trying to actually use the advertised functionality of the library. Issues include migrations being generated incorrectly, lots of footguns (for example it’s extraordinarily easy to instead of deleting a particular row, to delete your whole table, and their typescript typings are too general to make it clear what you’re doing), the pattern of making instances of relations that lack all the fields that are required in the DB leads to the type system becoming unreliable (fields that should always be present in the DB, may not be in JS), transformer functionality has a ton of bugs as well. I’m just scratching the surface, it’s telling that there are 1500+ unresolved issues on the repo and 200+ unmerged PRs.
The downside for me about dropping into raw SQL is that it makes much of the usefulness of an ORM in being able to refactor your schema and stuff disappear, because the type system and instrumentation can’t auto-refactor a raw SQL string. But I agree that I’d take that over relying on TypeORMs bugginess.
Thanks for sharing this insight, it makes a lot more sense to me now, saving this (in my brain) for the counter argument to TypeORM.
> I’m just scratching the surface, it’s telling that there are 1500+ unresolved issues on the repo and 200+ unmerged PRs.
So just a side note on this, I judge repositories based on teh ratio of closed to unresolved (and whether they have a bot that auto-closes issues). 200+ unmerged PRs is bad -- that maintainer needs help. I've interacted with the main maintainer before a long time ago and I had a good impression, but they probably weren't ready for how big their project got (how can anyone be) and they clearly didn't charge enough to make it a joy to work on their project. Money isn't the main motivator for everyone, but it would enable hiring people, or taking vacations as appropriate, etc.
Yeah, a lot of people have been saying that on the pinned mega-issue re the future of TypeORM - but the maintainer doesn't seem to have done much to fundraise nor pass on leadership to others. This seems to be moving slightly - some contributions are slowly trickling in. But at this point I think alternatives like Prisma will just eat the pie.
This matches my team’s experience with TypeORM. It’s full of bad surprises. We use it exclusively with a read-only account because we don’t trust it to change our data under any circumstance. Our current plan is to move to MikroORM, Prisma 2, or just give up on Node completely.
