First of all, they are legacy spec, they don't "just work", you need specific tooling/setup to support them (e.g. esbuild doesn't and won't, and a lot of modern tooling is build on top of esbuild, e.g. vite). And this won't get better, it will only get worse.

Second, the type-safety around them was always far away from perfect.

For those reasons, they won't be the default way to define entities anymore. I plan to rewrite all the docs examples to use defineEntity helper instead, primarily (but we'll keep the code tabs with decorator version too). So it makes sense to put decorators aside, document separately how to use them, and make the core package smaller.

Also, given the fact that there are two specs for decorators, it makes sense to have them side by side somewhere, hence the new package.

On the other hand, about a third of our users are using nestjs, and they won't likely move away from the legacy specs anytime soon. The question is, how many people are discarding the idea of using MikroORM because they still consider it as a decorator-based library.

Either way, this is not about dropping support for decorators, the main BC this introduces is that the decorators won't be defined in the core package anymore, and that is what the poll is about.

When I was testing how bundling with vite works in the current state of v7, the decorators are already successfully tree shaken, apparently, even if they are in the core package. When I saw that, I felt like keeping them in core for now might be the right step, hence this poll. I still want to put away the dependency on reflect-metadata, but even that on its own doesn't require moving the legacy stuff away from the core package.

I see. I think the way then is to go with a hybrid solution to support both ways and have as default the define entity as you mentioned. I am also planning to migrate my 71 entities from decorator to define entity before v7. Will be a hell of a journey 😅

I am using Mikro orm with nestjs and Postgres and next year as a beta app yet, next year will be launched to over 600 clients 🚀🚀

The good thing here is that you don't have to do this all at once.

Anyway, decorators won't go anywhere. I don't expect people to blindly migrate to defineEntity in their production apps, but I hope the defineEntity helper might attract new people, since it will provide no setup barrier and provide better type-safety.

Indeed, i am planning to go entity per entity. And maybe do that for the new ones only for now. Is good to do it now that is early for me, so we can seek for improvements if needed.

I am wondering for dtos like create / update if something like that can be used as well (maybe zod here) but anyways is out of scope for this poll

Jest is such a pain in the a** with ESM that I simply gave up. A couple of years have passed since then but I didn't receive notifications about the issues I've opened so I don't think it improved in that regard.

It really depends on how you use the ORM, many of those BCs are about things that people don't use very often, or are tied to the ORM config/discovery, so they're pretty well isolated.

In the getting started guide, the upgrade doesn't require any code changes, the only thing that you need to swap is the dependency on ts-node. Similarly, the nest realworld example app is also trivial to upgrade, the main issue there is using jest for tests (jest being a pain with anything ESM related is nothing new, I hope more people will move to vitest over time).

Sure, if your app depends on the current knex integration, that itself will likely hurt. For that I plan to provide a compat layer, e.g. you will be able to work with knex instances via raw() helper (already possible in v6).

I am mostly using knex for the getKnexQuery in some places. Will there be ways to replace such ? I suppose yes.

No, there won't be a direct replacement for qb.getKnexQuery(), you will need to rewrite this to use kysely or knex directly, there won't be a deep integration between the ORM QB and kysely one.

OK I only use it in 2 places so i can survive :D

AI is likely a very good candidate for such tedious tasks.