MikroORM v6

[B4nan]

Upgrading guide

https://mikro-orm.io/docs/next/upgrading-v5-to-v6

Update 05-11-2023

v6 branch is now merged to master and first release candidate it out.

Update 25-10-2023

Things are almost ready and I plan to merge v6 branch to master next week, and mark it as a release candidate. All the breaking changes and refactorings I wanted to do are already present, and there is one last feature I wanted to implement (which is not technically blocking anything and can land in a 6.x release too). I hope I will have time to finish the getting started guide and update the docs before the end of the year, and ship the stable.

If you want to help, now is the time to start testing v6. If you have a relatively large app that is well covered with tests, it would be great if you can try to upgrade and report any issues you find on the way.

Update 03-03-2023

One important feature landed - strict partial loading. This comes with a breaking change on type-level, the partial loading hint (fields option) now supports only string paths, like the populate option. Available for testing since v6.0.0-dev.44.

Update 03-02-2023

Most of the planned breaking changes are now implemented. I am still thinking about #3982 (was more sure about this at the time of writing, but now I am leaning towards keeping as-is) and #3989 (also not 100% sure here, maybe not worth it) and I also want to polish the reference/collection API a bit. I will probably focus on overall behavior improvements and docs rather than some big new features (like the polymorphic relations), as that can be implemented later via feature releases.

Update 03-12-2022

Initial v6 development started in https://github.com/mikro-orm/mikro-orm/tree/v6 branch. The branch is configured to publish v6 canary builds automatically. After some time, this branch will be rebased to master, until then, the docs for it won't be available. The initial migration guide WIP is here:

https://mikro-orm.io/docs/next/upgrading-v5-to-v6

---

I am slowly starting to think about what to do with v6. I'd like to ask for ideas, both feature-wise, and API polishment-wise - I'd like to rename some confusing options.

This list will be updated as time goes on, right now it's just a few ideas I keep holding in my head.

Renames

• PropertyOptions.onUpdateIntegrity -> PropertyOptions.updateRule
• PropertyOptions.onDelete -> PropertyOptions.deleteRule
• EntityProperty.reference -> EntityProperty.kind
• ReferenceType -> ReferenceKind
• PropertyOptions.wrappedReference -> PropertyOptions.ref (over time we might alias this to reference but let's not interchange existing options for now)
• AssignOptions.mergeObjects -> AssignOptions.mergeObjectProperties
• EntityOptions.customRepository -> EntityOptions.repository
• Options.cache -> Options.metadataCache

Removal

• PropertyOptions.customType in favor of just type (it already works with it), will keep the distinction on the EntityProperty interface level probably
• Options.type in favor of driver exports of MikroORM and defineConfig
• connect parameter of MikroORM.init in favor of the connect option in the config
• Configuration parameter from MikroORM.init in favor of the POJO options object (it was always meant to be internal)
• remove support for operator suffixes in query keys (e.g. id:gte), they were deprecated a long time ago
• em.nativeInsert in favor of em.insert
• em.persistLater, em.removeLater
• SchemaGenerator.generate
• PrimaryKeyType symbol in favor of PrimaryKeyProp

Breaking changes

• unify the loading methods of Reference and Collection, clean up the API (added Collection.load() method)
• remove the PK generic argument and replace it with PrimaryProperty<this>
• using this type in BaseEntity instead of explicit type arg
• FindOptions.fields will be an array of strings just like populate hint (needed for stricter type checks)
• require mappedBy in 1:m options (now its optional as it can be linked from the m:1 owner, but its confusing)
• refactor(core): remove persist/remove/flush methods from EntityRepository #4130
• feat(core): native BigInt support #4719

Features

• feat(core): re-export the core package from all drivers #3816
• feat(core): remove static require calls #3814
• feat(core): allow overriding ORM config path via --config #3924
• feat(core): add cursor-based pagination via em.findByCursor() #3975
• refactor(core): simplify generics in BaseEntity and PK type inference #3997
• feat(core): strict partial loading #4092
• feat(core): support atomic updates via raw() helper #4094
• feat(core): infer property type from default value #4150
• feat(core): allow mapping database defaults from inline embeddables #4384
• fix(core): use join on conditions for populateWhere #4025
• feat(postgres): add support for native enums #4296
• feat(core): add MikroORM.initSync() helper #4166
• feat(core): add GeneratedCacheAdapter for production usage #4167
• feat(core): require explicitly marked raw queries via raw() helper #4197
• feat(core): rework serialization rules to always respect populate hint #4203
• feat(core): add customizable LoggerContext with labeling support #4233
• feat(core): allow overriding global logging options on per-query basis #4273
• feat(postgres): add support for weighted tsvectors and a custom regconfig #3805
• feat(core): allow using Ref wrapper on scalar properties #4358
• feat(core): add support for indexes on JSON properties #4735
• fix(core): respect @Index and @Unique decorators on embeddables #4736
• feat(query-builder): allow joining sub-queries #4747
• fix(core): make em.create strictly typed for relations too #4752
• feat(core): add Opt type as an alternative to OptionalProps symbol #4753
• feat(core): support mapping one column to different STI properties #4769
• feat(core): allow populating collections with references #4776
• feat(core): respect updates to M:N inverse sides and batch them #4798
• feat(core): add discovery hooks onMetadata and afterDiscovered #4799
• feat(core): allow using dataloader for references and collections #4321
• feat(core): respect naming strategy and explicit field names on embedded properties #4866
• feat(sql): add native support for generated columns #4884

Other

• drop support for node < 18 lts
• require TS 5.0+ or even higher
• make allowGlobalContext warning more verbose and warn about its usage
• Change names of repository injection tokens to prevent overlapping with @nestjs/typeorm nestjs#106

[potb]

more powerful entity generator (generated prisma-like client?)

To me, one of the many selling points of MikroORM is the excellent typing without the need of code generation.

You don't have to add extra steps when deploying your application or onboarding new developers into your project. It just works.

In my opinion, that would worsen the developer experience for a little improvement type-wise.

[B4nan]

To me, one of the many selling points of MikroORM is the excellent typing without the need of code generation.

It would be optional way to use it, basically to unlock schema first approach for those who want it. Everything would remain working as it is now.

[potb]

In that case, that would be a pretty nice feature to match what Prisma has to offer !

[alexbudure]

Exciting! One feature suggestion I have is supporting cursor based pagination out of the box

[B4nan]

Btw with the serialized cursor strings, we keep both the cursor values and ordering, would it make sense to infer the ordering when cursor is provided this way?

edit: oh wait a sec, it's not there, got myself confused when implementing this

[B4nan]

8f3bd0b

[winsontam]

will it add to FindOptions later?

[B4nan]

? The commit mentioned above did it

[winsontam]

? The commit mentioned above did it

Oh sorry, i see it.
Wow, really cool.

[axotion]

I would really like to see a migration file generator combined with a more complex entity generator. I've even tried to write some PoC
MikroORM Interactive Generator

IMO it could save a lot of dev time

[dragurimu]

For me polymorphic relationships are something quite interesting, maybe an approach like laravel eloquent.

[Langstra]

Agree, for me polymorphic relations would be a great feature to have

[axotion]

It's a nice feature, but from my experience, it really can reduce performance of application dramatiacally. I'm afraid that people could overuse it and end up with a huge mess.

[hayksaryan]

I recommend reading this article: https://docs.gitlab.com/ee/development/database/polymorphic_associations.html

I've opted out of using polymorphic relationships based on the article.

[AbdlrahmanSaberAbdo]

I recommend reading this article: https://docs.gitlab.com/ee/development/database/polymorphic_associations.html

I've opted out of using polymorphic relationships based on the article.

Thanks for the article, I don't like to use polymorphic relationships in many cases, but it could be helpful for audits, I mean for keeping track of database changes.

[rcfox]

How about trigger/function support in migrations?

A function could just be a raw query as a string inside of a class with a name and inputs, or something like that.

Triggers could be additional decorators you add to Entity()-decorated classes to specify the function and when it should be triggered.

I don't think any run-time behaviour would be needed, just metadata tracking for migration revisions.

[B4nan]

Does it really make sense to add any kind of abstraction here? How is this different than defining your trigger directly in a migration file? You'd have to write the full SQL for it anyway, why not create a blank migration and put it there instead of creating some class or whatever. I don't think this should be some decorator, trigger is not bound to a table, it's a general-purpose function, right?

[rcfox]

The problem with just putting the SQL in a migration file is that part of your database definition is now separate from the entities, which should be the main source of truth when using the ORM.

Migrations are files run in sequence to mutate the state of the database at each step. There's currently no one place you can point to to see the definition of a function or a trigger as a later migration could change an earlier definition.

There are two parts to a trigger: the function that runs, which is general-purpose and not directly tied to a table; and the trigger definition that says "when an operation runs on this table, run this function." For example, you could create a trigger that runs whenever a row in table_a is updated, and inserts a new row to table_b to record that that happened. (I wouldn't expect it to acknowledge the behaviour of the function, just that the trigger is registered with table_a.)

Having database functions alongside the table definitions would allow developers to have a more complete view of the state of the database. Giving them identities within Javascript/Typescript would allow the schema generator to ensure that the function you're referencing does exist.

[co-sic]

I would like to have something like this too. I wanted to add audit tables for each entity which work with postgres triggers, but i don't like the idea to put the SQL statements just in a migration file. Especially if you change something in your entity code its easy to forget to change the DDL of the audit table too. It would be less error prone if i would be able to define it in my Entity code.

[kpervin]

I feel this would be nice to have as it could also tie into schema:fresh --run for CI/CD pipelines. By having them defined on the entity, it goes with what @rcfox was saying by having it all observable on the entity instead of having these triggers duplicated in both a migration as well as a file to be run alongside schema:fresh. The more DRY when defining your DB, the better imo.

[lagnat]

See #3567 (comment) for context.

change how type instances are created, so they always have meta/prop/platform properties? require them in constructor?

I would prefer to own the constructor. Perhaps call the necessary setters during metadata initialization.

Edit: This is how I'm faking it today

    override getColumnType(prop: EntityProperty, platform: Platform): string {
        this.prop = prop;
        return super.getColumnType(prop, platform);
    }

[malekim]

1. Unit testing possibilities
2. Documentation for unit testing

[kpervin]

Would be nice to have a concrete unit testing section, and also one in the NestJS section. Namely some examples of expected best practices, especially surrounding global context.

[B4nan]

The getting started guide now covers this. Will try to add some examples of mocking too, now its rather simple.

https://mikro-orm.io/docs/next/guide/project-setup#testing-the-endpoint

[pawelsmolenski]

I would like to see an EntityAssigner being able of assigning nested structures reflecting model relationships. I am working on a R&D type project where often complex objects (several levels deep) of input data are sent through GQL mutations API in a single request and atomically stored as a structure of entities in RDBS.

As a POC, we managed to modify current EntityAssigner, by adding lazy loading of entities potentially affected by the input structure (that required a change of its synchronous behavior into asynchronous). This solution has been developed as manually handling those input structures in would be cumbersome – especially knowing, that their shape is identical to the data model. At first glance, this seems to work, but probably not all pitfalls have been analyzed by us.

[rubiin]

We can port many features from doctrine and elquoent orm. Some of the ones i like to see are

1. More collection methods https://www.doctrine-project.org/projects/doctrine-collections/en/stable/index.html#collection-methods
   https://laravel.com/docs/9.x/eloquent-collections#available-methods
2. More on migrations such as dry run and version aliases
   https://www.doctrine-project.org/projects/doctrine-migrations/en/3.5/reference/managing-migrations.html#managing-migrations
3. https://laravel.com/docs/9.x/eloquent#replicating-models
4. https://laravel.com/docs/9.x/eloquent-resources#pagination
5. Add benchmarks maybe . I think we had that earlier

[JaneJeon]

I understand it's already possible to instrument the underlying knexjs itself; however, it would be very useful to see some form of OTEL/opentelemetry support implemented at the mikro-orm level (akin to prisma) to be able to see how the "groups" of seemingly random knexjs queries can be traced down into a particular mikro-orm flush, for example.

[B4nan]

A recent addition to v6 is EM bound logger context - which automatically contains the current EM id, so you can use that to see which fork created which queries. You could modify the context automatically via flush events I guess, to add a notion of flush id too if that's any better than the EM id itself.

https://mikro-orm.io/docs/next/logging#providing-additional-context-to-a-custom-logger
https://github.com/mikro-orm/mikro-orm/blob/master/packages/core/src/EntityManager.ts#L2106

The logger also has built-in support for labels, so you can use that with the default logger to add anything to the queries easily.

https://mikro-orm.io/docs/next/logging#query-labels

(they can be set via the logger context too)

[xenoterracide]

have persist also return hydrated entities including calling load hooks. This is especially important if save is called with a partial instead of a full entity that wasn't loaded if the first place.

[B4nan]

persist is not returning anything (the method has a fluent interface so returns the EM instance), it only marks entities for future persisting when flush occurs. And you get full support for hooks with flushing. Note that load event has nothing to do with flushing (or updating entities), that is fired when loading entities via em.find and similar.

So I don't really understand what you mean by this.

[xenoterracide]

So Spring Data doesn't actually do a flush immediately (same as persist), but the save method returns the proxy (or other method). A subsequent find will force a flush (doesn't seem to happen, I created a bug by not testing with identity map disabled off). What I'd like is a method similar to persist that returns the final objects, possibly flushing and doing a query as necessary. It also needs to do any load actions, so that the returned object can be treated the same as if I had done a find.

does that make sense?

https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#jpa.entity-persistence.saving-entites
https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/repository/CrudRepository.html

[B4nan]

Not really, still quite confused. Sounds a bit like you want em.upsert?

https://mikro-orm.io/docs/entity-manager#upsert

[xenoterracide]

maybe, although upsert even existing in conjunction with persist is quite confusing to me, they seem like they should be doing the same thing (also upsert is weird for mongo)... or rather it seems like persist should use upsert under the hood. also it seems that

EntityRepository does not have upsertMany

import { EntityRepository } from '@mikro-orm/core';

upsert doesn't match the same signature as persist, and so doesn't seem to want (without casting) to accept the parameters I'm using.

[xenoterracide]

it also seems to resolve in

    DriverException: Performing an update on the path '_id' would modify the immutable field '_id'
    Query:

[TheNoim]

My wish would be a native esm build of mikro-orm.

[B4nan]

What problems do you have with ESM? The new (unreleased) getting started guide is ESM project and (while there are a few quirks) it works fine, so I hope this is more of a documentation issue. One of the problems I am aware of was the static require calls we had on a few places, but that is already gone from v6.

[B4nan]

Maybe we should also move the where parameter to FindOptions to simplify the em.find interfaces?

Poll here: #3982

[B4nan]

Another RFC here: #3989

[B4nan]

v6 has em.findAll() which supports where option, so we kinda have both now.

[productdevbook]

ClickHouse support can be added

[Langstra]

I hope we can get this feature in v6. Although already discussed I thought I'd mention it here anyways: #3768

[bigtechsolution]

When will v6 be released, do you have a set plan?

[B4nan]

No idea, I work on this in my free time, can't give you any set plan. Unless you want to sponsor the development - I'll be more than happy to focus on this :]

[B4nan]

In case you missed it, the latest v6 dev version (dev.44) has now strict partial loading support!

https://stackblitz.com/edit/mikro-orm-v6-strict-partial-loading?file=basic.test.ts

What other places could be more strict or better typed?

[B4nan]

Loaded collections also have the magic $ getter, you can use that to detect loaded collections on type level, so I am not sure why would you want this?

[B4nan]

Is this about entity references (so entities that are not initialized)? I could understand that, I see those don't have the collections available (while on type level they are there). But maybe it would be better to define the collections there instead of messing with the (already pretty complex) types?

Maybe provide some code so its clear what problem you want to solve and how could the solution look like.

[co-sic]

I didn't know about the $ getter, nice! But i would still prefer if the collection was not there since i can still call getItems() directly on the collection without getting a typescript error.

So if we have the classic author book example and i do the following

const author = orm.em.findOneOrFail({id: 1}));
console.log(author.books.getItems());

i would get a runtime error but no typescript error. I can get around this with fields

const author = orm.em.findOneOrFail({id: 1}, {fields: ['name']}));
console.log(author.books.getItems());

now i will get a TS error.
I just want to have the same functionality without having to specify fields manually.

We have a lot of connected entities and sometimes the populate goes 4-5 levels deep and i would need to manage both populate and fields simultaneously for that to work. I just like the idea, that if you don't pass anything (populate or select), then you also can't access the collections, refs, only the properties that are directly on the entity, or if i passed a populate. Like this you will be more likely to detect an error in your code because typescript has your back, no matter what options you pass to the EM. We had some bugs already where a populate was not added and it was missed in the review stage (of course you can get around that with good tests etc. but would just be nice if TS could help there). So of course i understand this is something tailored to my workflow with mikro-orm, but if it could be achievable without to much work, that would be awesome.
To me this sounds like a sort of "auto-fields" option, so if i don't specify fields, the fields that will be returned from my query are automatically selected and the type will behave accordingly.

Not sure if this was clear, i can also provide a bigger code example if you like.

[B4nan]

Collection.getItems() is like Reference.unwrap() - that is not the type-safe relations approach, that's the "backdoor". You should be using the $ to ensure things are loaded.

const author1 = orm.em.findOneOrFail(1);
console.log(author1.books.$.getItems()); // fails to compile

const author2 = orm.em.findOneOrFail(1, { populate: ['books'] });
console.log(author2.books.$.getItems()); // works

FWIW I don't see any way to change type-level behavior globally, that sounds like too much to ask, and I don't think this should be the default behavior, that would be heavily breaking.

[co-sic]

Yes i can understand that, thanks for the answer 👍 I also didn't know about the Ref wrapper, so i can get the typesafety by using $ on Refs and Collections.
I still would wish there was a way to enforce this behavior, because if you forget to use $, then you still have the same Problem. Maybe i can build a custom eslint rule for that, let's see :D

[oojikoo]

How about FOREIGN TABLE(https://www.postgresql.org/docs/current/postgres-fdw.html) support? but this might be an exclusive feature for postgreSQL, though.

[acommodari]

What about integration with postgres.js for potential performance improvements?
Their benchmarks page seems promising and I've seen some other ORMs/runtimes start to support it 🤔

[PrimeDominus]

Great idea!

[LeulAria]

What about integration with postgres.js for potential performance improvements? Their benchmarks page seems promising and I've seen some other ORMs/runtimes start to support it 🤔

was this introduced ?

[hayksaryan]

I'd like to see an option to enable logging only on a specific flush (em.flush()), instead of doing it globally.
The API would look like em.flush({ logging: true }); or em.flush({ debug: true });

[bill-o-more]

I'd love to have a bringItems() method on a Collection, which will init() it if not initialized, and then return the results of getItems() 😊
Motiation - usually, when I need some collection items, I don't care if it's initialized or not - I need dem items, so having a convenient helper method on a Collection itself would help to keep things cleaner :)

Could probably PR it

[Langstra]

How about using loadItems? If the items are there or not, you can simply await it and get the items.

[bill-o-more]

yeah, to use it one needs not to miss it in the docs. Thank you!

[acommodari]

With Decorators and Decorator Metadata now at stage 3 for TC-39 and with Typescript 5.2 bringing the metadata implementation I'm curious if this library plans to pivot to the official decorators in a future major (v6-v7)? Or will this be something done in the longer term? Since this is an all or nothing change and you can't mix and match old and new decorators.

[B4nan]

I'd like to move to ESM only in v7 most probably. And I'd say there is a way to support them in v6 too, worst case through a different export/name.

[octet-stream]

I think different subpath would do it, or different package. Like @mikro-orm/core/decorators or @mikro-orm/decorators

[PodaruDragos]

FWIW native decorators won't work with most decorators libraries, not until the proposal for parameter decorators is implemented ( if it ever will reach stage 3. It's now at stage 1 and with not much interest ). I understand why people ask for this, but as it stands now it's not possible.

[B4nan]

How are parameter decorators related to MikroORM? Or you mean in general, to be able to adopt them? I can see how problematic it would be for DI libraries, where constructor injection via decorators is very common.

[PodaruDragos]

I am talking in general yes, Mikro could go away with it ( probably ). With the new metadata proposal you could also ditch reflect-metadata ( I know it's now the same thing as the proposal, but it might as well just work ). Native decorators are way better since you can type things now properly. I've been researching a way to drop reflect-metadata in inversify also so I am happy to chip in if you ever want to go that path.

[lsndr]

What is the purpose of removing persist and remove methods from repositories?

I expect repositories to be collections of objects. So in this sense, it's ok to remove flush. But without persist and remove repositories are not repositories anymore.

[B4nan]

All of the methods that were removed were just shortcuts for the EM methods, and unlike the other repository methods, they ignored the current entity type, e.g. you could persist/remove a Book entity from Author repository, so it felt a bit confusing (just like flushing the repository, as you don't flush it, you always flush the underlying EM).

IMO repositories are mostly overused, at least that's what I see from the issues. People blindly use repositories for everything, while using EM would be much cleaner and simpler. I think they should be used mainly as extension points.

FYI this ORM was inspired by doctrine, and there the repository also does not have any of those methods:

https://github.com/doctrine/orm/blob/2.16.x/lib/Doctrine/ORM/EntityRepository.php

---

With that said, I am open to discussion. If there will be way too many users asking to see them back, we could surely add them back. You can as well put them into a custom base repository yourself already.

[minhchu]

@B4nan mikro-orm is really excellent. Just tried it a couple of days and really love it. At first I tried to use Repository<Entity> but later I find myself only use EM and Entity.
I think many of us (developer) are familiar with Active Record pattern so many people are using repository, because it give us some sort of syntax like this.repoModel.find(id). While this.em.findOne(Model, id) is a bit strange.
I think the document can improve to onboard new developers. For example: the installation & usage section is mostly about installation. It should show some examples of doing some basic queries.
Maybe you should try to do some marketing things to spread mikro-orm to the world. At my company, I want to persuade my boss to use Mikro but when he looked at github stars (mikro vs prisma vs typeorm ...) so ... ehhh.

[B4nan]

Check this out, it's not complete yet, but it covers the basics pretty well already

https://github.com/mikro-orm/guide

[rubiin]

Adonis lucid orm which my other office project is currently using has some features that Mikroorm can import. One thing would be to add more querybuilder methods
https://docs.adonisjs.com/reference/database/query-builder

[kpervin]

Are there any specific methods that Adonis provides that you'd want to see in MikroORM? At present the MikroORM query builder seems complete enough to satisfy most if not all query building needs.

[rubiin]

the where variants. https://docs.adonisjs.com/reference/database/query-builder#where-method-variants

[kpervin]

Do you mean the not variants?

[rubiin]

Yeah . But scratch that. This would be better so anyone could extend the query builder and add in methods they like
https://docs.adonisjs.com/guides/database/query-builder#extending-query-builders

[B4nan]

I don't really see much value in those methods, that doesn't bring anything new to the table... MikroORM supports various operators to help with this, and those cover pretty much all the different where signatures of adonis.

There are indeed some things that the QB is not capable of, like joining a subquery, or using lateral joins. Some of them are blocked by knex not supporting them.

[xudongcc]

@B4nan Hello, is dataloader support not in the v6 release plan now?
#4321

[B4nan]

Uh, that's weird, must have been some bad rebase, this is indeed not intentional, thanks for the notice.

[B4nan]

cc @darkbasic, do you want to PR this again, so you stay as the author of those changes in the git history? if you don't care, I'll be happy to do it myself, as in the end, it's me who messed up with the rebase - I really hope I did not loose other changes too 🤦

[darkbasic]

Sure I will PR that again, but wouldn't be safer to restore from a backup before the rebase to be sure you didn't loose other changes?

[B4nan]

I think what happened here is that I was rebasing and forgot to pull first, so I've overridden the upstream, it's not from the rebase itself.

[darkbasic]

That sounds bad because you would have basically lost anything which got merged into v6 from that point onward.
I would personally retrieve the previous HEAD for the v6 branch from the reflog and rebase once again from that commit.
Alternatively, if you're sure you didn't loose anything else, you could try git cherry-pick 53b9ca10c2eed402c4643aa0d2096f371edbb837 to retrieve just the dataloader. If that doesn't preserve the git history somehow let me know and I will create a new PR.

[bozorgmehr96]

Do you have any estimate of when it will be released?

[B4nan]

The first week in January most probably, I got one last thing I wanted to implement (plus a blog post), but didn't want to do the release over Christmas.

[B4nan]

FYI I am targeting this friday, everything I wanted is implemented now, I just need to finish with the blog post plus a bit of docs updates.

[dungkaka]

I can't wait, hope MikroOrm grow much in 2024, it deserved 1000 times.

[patrick-petrovic]

Our codebase is so ready to upgrade 😎 Great work!

[B4nan]

The work on the blog post is going a bit slower than I expected, so it might happen on monday morning instead, I won't be releasing it over the weekend most probably.

[fa-sharp]

Just wanted to say, I love the new Getting Started guide in the 6.0 docs 😍

[nicomouss]

Just installed v6 to test along our codebase. Works great !
(Needed v6 to properly use embedded entities having custom fieldnames).

For some reasons for the time being, I have to use a node version < 18. Although the v6 release changes indicate a "drop support for node < 18 lts", everything is working fine (using Postgresql driver at least).

Does this requirement about the node version affects only some specific mikro-orm functionnalities on some specific drivers ?

[B4nan]

WDYM "for some reason"? The engines constraints shouldn't let you install node < 18. Sounds more like you have some unrelated dependency that required node 16 to me.

Technically, this is just a version bump as node 16 is EOL. What changed is the TS compilation target (and many dependencies also state they require node 18 now, probably in a similar manner).

[nicomouss]

WDYM "for some reason"?

"for some reason": meaning I am currently working on a machine where a node version < 18 is installed (for some other reasons not linked to mikro-orm). So I am basically running mikro-orm v6 on node 17.9.1 (< 18), and it works fine so far. Was wondering if there would be any blocking points down the road (so far so good), hence my request for clarification.

The engines constraints shouldn't let you install node < 18.

I am using npm, and by default an engines constraint in package.json doesn't prevent installing. It just triggers some warnings if your working nodejs version does not match the engines constraint of the library you are installing.

Technically, this is just a version bump as node 16 is EOL. What changed is the TS compilation target (and many dependencies also state they require node 18 now, probably in a similar manner).

All good then ! Thanks for clarifying.

[B4nan]

Oh, I thought you meant you are not able to run it on node > 18, it can indeed work with node 17 too although that can (and will) break over time most probably.

[nicomouss]

Yes, it will definitively break for sure at some point.
At least for the time being I can keep working with the constraint(s) I have, so all good !
Coming from NHibernate and Domain Driven Design philosophies, working with Mikro-orm is delightful !
Thanks again for your replies and keep up the good work !