Micael Levi L. Cavalcante

ping @mcmath

I've just created an action to find the last updated issue that has the given labels: https://github.com/marketplace/actions/find-last-issue I tested it here: https://github.com/micalevisk/awesome-nestjs/issues/5 As you can see, the issue was updated...

I'm no sure if we should add yet another decorator. There are too much decorators already :thinking: What about: ```ts @UseInterceptors(new ClassSerializerInterceptor({ returnType: UserEntity })) @Get() findOne(): UserEntity { return...

I was expecting a lot of edge cases for the REPL tbh I'll investigate this issue tomorrow

another thing on this issue:  it is always selecting the provider registered on `CatModule`  

I'm using your repro repo. It is `repl(AppModule)`

if we drop the `this.globalScope[stringifiedToken]` assertion below and change that `configurable` to `true`, `debug()` will display the desired output  https://github.com/nestjs/nest/blob/34cb6001c30b3e2d2a9570bc87c6bd78a8c49524/packages/core/repl/repl-context.ts#L81-L87 https://github.com/nestjs/nest/blob/34cb6001c30b3e2d2a9570bc87c6bd78a8c49524/packages/core/repl/repl-context.ts#L91 but that didn't solve this another issue: ```...

@BrunnerLivio > though even with `select(CatModule).get(AppService)` it will select the `AppService` of `AppModule` - not the one from `CatModule`. we need to supply `{ strict: true }` to the `get()`...

due to the above described behavior, `$(duplicatedToken)` ends up returning the wrong provider like so:  but if we use `strict: true` below, we got a _Nest could not find...

@ologbonowiwi another bug that I believe isn't directly related to this issue is that: when we have a provider with the same token registered in multiple modules, the latest registered...