Nest.js is a great framework, with excellent documentation, but it can be quite heavy weight (from a coding and concepts perspective) and alienating to JavaScript devs without a background in C#/Java.
Its basically Spring/.Net MVC implemented in TypeScript. That makes it a great choice for .Net/Java developers who are transitioning to coding for Node.js, but for anyone without that background, it comes with a steep learning curve (Dependency Injection, Inversion Of Control, Aspect Oriented Programming... all the usual suspects of "enterprise" application development).
I'd say its positioned to become very popular (and you can see its trending strongly upwards on npmtrends.com) because so many enterprises are transitioning towards Node.js. Its like a cozy blanket for ex .Net/Java developers.
I always find it amusing that that Nest.js is a back-end framework, that was inspired by a front-end framework, which was inspired by a back-end framework. (Nest.js -> Angular -> Spring MVC). :-)
The dependency injection seems to miss the point of dependency injection though. I'd love to be proven wrong but, in the documentation, under the providers section [0], they seem to be wiring CatsService directly as a concrete implementation because, I guess, interfaces are erased in compile time. In C# such problems don't exist. Weird, as they also mention SOLID.
Its true that, by default, you use a Class when wiring up the DI container because as you guessed, the interfaces are erased during transpilation.
You can still achieve the loose coupling of DI by using custom providers [0]. Basically, this approach is the full syntax for defining providers and gives you the most flexibility (inject based on Class or token, provide factories, simple values, class instances, etc).
[0]: https://docs.nestjs.com/fundamentals/custom-providers#custom...
Anyway, IMHO, Typescript isn't designed for dependency injection in mind. Microsoft also has a DI library [1] but it feels like too much wiring to compensate for the lack of compiled interfaces.