Earlier quoted context omitted.
Yeah, I don't know, most of the time only time you actually need dep injection is for tests, and at that point why not just mock with Jest? Feels too much just having to do all this work just to complicate dependencies and make moving around more difficult for tests when a much simpler solution is available.
Dependency injection was not really meant to help with testing, but to keep code decoupled. It can be a nice pattern, but even if nestjs forces us to do it, we developers still find creative ways to nullify any attempts to decouple the code we write :).
To me in most cases it is used it seems to just overengineer and obfuscate things unnecessarily when much simpler code would be easier to understand, etc.
It shouldn't be a thing that is done by default, only when it really makes sense.
Eventually with all those injections you are going to cause a situation where making any changes becomes really complex, if there are any use cases you didn't foresee at all.
In 90%+ cases you don't need interfaces and or DI, you should just be able to follow the logic with your IDE, it makes no sense to obfuscate that.
If the impl truly must vary for whatever case, then sure, you can use it.
But I would also say that don't do interfaces and impl before you actually need to switch them out dynamically depending on the context (and not just for testing).
If you have something that does Storage, and Storage drivers could be different like FileSystem, GoogleDrive, whatever, then sure use an interface, but not otherwise.
It's like DRY. Unless you actually use it 2-3 times, don't make everything unnecessarily into a reusable fn.
If you don't foresee having multiple storage methods in the near future then just use a class for storing which you can move to, to see how it does file storage or similar.