Closed proohit closed 1 year ago
you can make the helper function in your side. I don't see any reason to move that to @nestjs/typeorm
. It will just increase the API surface.
We could instead improve the doc around TypeOrmModule.forFeature
to clarify what it does.
@micalevisk thanks for your blazingly fast answer :D .
I did it on my side and use it actively, yet still couldn't help but think that this a very common use case, so why not make it a 'standard'. I agree however that this would be an additional point for potential breaking changes, which makes maintainability a little harder.
I'm not sure on that. I'm pretty familiar with .forFeature
. If I have a helper like that I wouldn't know what it does. And .forFeature
follows a well-documented convention, so, to me, it's easier to understand it rather than UseRepositories
(even tho this one has a good name)
Anyway, if you don't want to wait for Kamil's response, go ahead and open a PR at https://github.com/nestjs/typeorm :cat:
Thanks for your suggestion!
There are no plans to implement it in the foreseeable future.
If you think your request could live outside Nest's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
Not a problem, but a suggested improvement of the developer experience for the typeorm integration. It is for one cumbersome how to use and not very clear what
TypeOrmModule.forFeature
does.Describe the solution you'd like
Teachability, documentation, adoption, migration strategy
Possibly export this in
@nestjs/typeorm
and use it forimports
in a@Module
:Now repositories for
SomeEntity
andSomeOtherEntity
can be injected:What is the motivation / use case for changing the behavior?
I think the most common use case of
TypeOrmModule.forFeature
is to be able to inject repositories, so I would suggest a helper function to make these imports more explicit.