это тестраннер

это не отвечает на мой вопрос)

ну я то в курсе) Вопрос в другом

ORM это не библиотека, это слой в архитектуре приложения, который решает проблему сохранения и вытаскивание бизнес объектов из хранилища. Сама по себе библиотека автоматически не становится ORM, даже если в её описании так сказано. Миграции тоже с ORM не связаны.
Скорее всего ты используешь библиотеки по типу Sequalize как удобный инструмент доступа к таблицам бд, а не как ORM слой (мне кажется таких большинство).
Советую изучить что такое на самом деле ORM, что такое Active Record, Data Mapper, Repository

орм как и билдеры, решает проблему незнания разработчиком скл, и призван удешевить разработку за счет этого. На практике так, правда, происходит далеко не всегда :)

Это неправда. Для норм использования ORM обычно надо знать SQL.

А знание SQL не решает, например, проблему разбора результата после толпы джойнов на вложенные сущности и наоборот

Если под ORM подразумевать библиотеку в описании которой написано что это ORM, то согласен. А вообще ORM как слой архитектуры не эти проблемы решает

JS, как и многие другие языки решают проблему незнания разработчиком ассемблера и призваны удешевить разработку за счет этого)

и тоже не всегда, иначе не придумали бы wasm и сишные апи

Можно и самому сделать слой ORM в приложении на сырых sql запросах без query builder

но зачем, не понятно

Можно и из хлеба сделать троллейбус

Ну как не понятно, абстракция же

собирать уже полученные данные в нужную структуру проще, чем собирать запросы

а главное - понятно что происходит, как это эксплейнить и дебажить, как искать ботлнеки, и тд

в случае с орм все то же самое, но разработчикам надо еще воевать с самим орм, изучать и поддерживать его. Мне не понравлось.

Орм маст хев, если у вас сложные запросы в sql, то стои переосмыслить логику проэкта

Потом окажется, что такого собирающего кода куча, придётся делать абстракцию/либу, потом её развивать и поддерживать, в итоге появится ОРМ, только сырая и неудобная)