**👇🏾 How to Choose a Library Without Shooting Yourself in the Foot

# [ $davids.sh ] · message #156

**You're looking at a library on Github and can't understand whether to use it or not

I'll write down a set of actions that I take:

– Read the release code – if the library is supposed to be developed, but the releases were a long time ago or they only changed the documentation / one line of code, then it's bad

– How many contributors are there and how often do they commit

– Read the Issues (especially closed ones) – how many are closed, how long ago, how many are open, are there any critical moments for you. I've found libraries where the authors simply closed all Issues without a response and people were left wondering what was happening.

– How many questions and answers are there on StackOverflow, if there are many, then it's good

– How many articles are there on the internet about the library **and what dates they were published

**– It's better if the library doesn't depend on a lot of other libraries, because if you need to contribute, you'll have to make changes not only to the library itself, but also to its dependencies

– It's better if the library is within one stack – for example, in Prisma, you'll also have a Rust library for translating queries to SQL, which means that to fix a bug, you'll have to edit not only JS / TS code, but also Rust

– Are there tests for the code – if there are, then it's better than documentation

**Example with Objection.js

**Under the post above, someone asked what I think about Objection.js, I went to refresh my memory, because I haven't used it in a long time:

– There is a fresh release, but it's the only one... before that, they didn't use releases, so we go to commits and see that commits are made every six months... for an ORM – it's very bad, because databases and database tasks are constantly evolving, which means the ORM should be too

– Among the contributors is the creator of Knex – this is good

– We go to Issues and see that the creator can't maintain this library (and no enthusiasts were found) and he himself calls it outdated

We can stop here and draw a conclusion – the library is dead

@ Taras 🫧 · # 298

Basically, there's already hate for TypeORM and Prisma, all that's missing is Sequelize.
It's always interesting to hear the opinion of a competent person about a particular technology.
@ Ivan ITK 🚫 · # 299

I'll add it to the next iteration about ORMs on the topic of locking patterns (the post was written a few months ago, so it's necessary to check the relevance of changes since then):

In Sequelize, there is a mechanism for optimistic locking through versioning, but you need to be aware of it. By the way, I couldn’t find any instructions in the documentation, only in the tests, which mention that you need to specify version: true in the model parameters to enable this mechanism in mutating queries. They also implemented a check: if no rows are affected during data mutation, it means the document version didn’t match, and it throws an OptimisticLockError.

In Prisma, there is an issue, and it’s delegated to developers. I found a solution 2 months ago by adding the capability to the query builder to implement your own optimistic locking.

The leader, perhaps, is only TypeORM for having the best documentation.

Regarding Mongoose. You can use the mongoose-update-if-current plugin. It implements optimistic concurrency. However, you’ll need to override updates using the .save() method.
@ [ $davids.sh ] · # 304

Cool)

The only thing I wouldn't call a "problem" is that optimistic locking is left to the developer to implement, in the sense that the implementation at the level of a single table isn't super complicated, but handling rollbacks in case of a lock error can become a bit of an issue, so I would always leave this to the developer's discretion.

And as always, my gripe with ORMs is that you always need to remember how exactly a particular lock will be implemented across different databases (yes, only TypeORM docs have such descriptions), and the advantage of "switching databases" here, in my opinion, doesn't fully work because when you start using optimistic/pessimistic locking properly, you definitely need to understand and utilize the capabilities of a specific database.

But again, as they say, IMHO)