-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: resolve issue with ordering of middleware being applied #189
fix: resolve issue with ordering of middleware being applied #189
Conversation
…`forRoot` registering to resolve issue with ordering of middleware being applied
i cant say i like the naming, the word |
The module doesn't just handle the middleware it also handles registering multiple |
the user still needs to do the strictly speaking, the renaming of various symbols and types is a breaking change, i would rather keep the old naming everywhere |
Yes the user would be required to Yeah I understand adding the new |
@B4nan, I have added additional tests and a test to show the issue arising; I have also found that this issue also occurs with the original middleware registration within |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
few notes to begin with, the main takeaway: lets rename all the symbols from Multiple*
to just Multi*
, feels like better english to me
also be careful with all the renames, there are still breaking changes in this PR
Co-authored-by: Martin Adámek <banan23@gmail.com>
@B4nan updated based off your review |
looks like your approach is not working with nest 11 |
i will give it ago with nestjs 11 |
maybe the problem you were trying to solve is no longer valid with v11? that's the first thing I would try to verify |
Yeah I notice some module changes and will go through it, if its fixed I will just leave the tests in to make sure its working to what I was expecting |
I've done some quick investigation on this, so with nestjs 11 they have changed the way how module distances are calculated with global modules and with the latest change it makes the global module middleware get executed last. I will raise an issue on the nestjs repo to see what they say. |
The issue has been resolved https://github.com/nestjs/nest/releases/tag/v11.0.5. With the fix |
@B4nan I have updated the |
why? because of something that was present for years now, in 10.x versions that are still supported? i would keep the peer deps loose, its up to the user to stay up to date. we can enforce this in v7 where we disallow older nest versions, but now it feels a bit weird, especially since it doesn't affect everyone (as mentioned above, the real-world example app still works just fine without any changes, even with lower versions). |
do i get it right that things without your PR worked fine, and with the changes you did here it broke with v11 before 11.0.5? |
My changes were mainly to resolve the issue in 10.x where the middleware registered in a global module it could be executed later and the test I made here we were able to catch an issue in nestjs 11 where it made the issue worse due to a bug where it made the global module middleware execute last hence why we should force to go from |
If we get this fix in then for nestjs 10.x we can remove this line https://github.com/mikro-orm/nestjs-realworld-example-app/blame/a61ea041db0d0cf24f32f49b262c5bfecd6a726d/src/app.module.ts#L32 in your example project |
Oh, now that's interesting, didn't realize it's about this. Agreed that it makes sense to merge it in. Let's keep it I guess, since the bump is not released out, I guess its fine to enforce first usable version. |
When setting up the nestjs modules with MikroORM there is a chance it can throw
Using global EntityManager instance methods for context specific actions is disallowed.
when interacting with the EM within another middleware.This fix applies to both single and multi database set-ups.