Yes, and by far the worst part of them is the dependency hell problem of a sufficiently mature front-end. It gets sand in your cornflakes during development, testing, and debugging.
Imagine you're writing a front-end in this mature codebase. What injection bindings do you need to instantiate a FooUIWidget, which contains a BarUIWidget and BazUIWidget, and a few new data types, relevant to the business logic of FooFeature?
Who the fuck knows! You have a rabbit's nest of nested dependencies, you have no idea what part of the system owns which data change, or what cascading effects that data change has. Oh, and when you decide to move FooUIWidget out of ParentUIWidget into UncleUIWidget, good luck figuring out which dependencies it needs, which need to be removed from Parent, which need to be added to Uncle, which need to have alternative bindings added (Because Uncle already provides them, but they are not what Foo needs - your code compiles, and gets no run-time Dependency Injection errors, but your values are silently bound wrong behind the scenes.)
Unless, of course, you do something sensible, and instead of having each bit of your system depend on 20 things provided by dependency injection, just build the bloody thing right the first time, by using event listeners and MVVM.
 Oh, and of course, neither your compiler, nor your DI framework is mathematically capable of telling you that half of the dependencies you're providing for Parent are no longer used for anything. Go get your coal miner's hard-hat, finish up your will, sign the waiver about black lung, and go delving through your dependencies.
How is SOLID responsible for these issues? The acronym represents guidelines.
What you are describing sounds awful. IoC can get nasty when developers are inexperienced and off-the-leash.
Keep in mind that everyone is ignorant. We all have different experiences with different technologies on different codebases.
It's the domain where proper architecture matters the most, because it's hard to get it right.
> It sounds like you are pointing out specific issues that you encountered when working on a particular project.
If by 'particular project', you mean every single FE project that I've worked on, that made unopinionated use of dependency injection, sure.
> How is SOLID responsible for these issues?
'LI' doesn't do any value add for these problems (You don't use all that much inheritance, or define very many interfaces when working on front-ends), and 'D' is actively harmful, because it paves the road to dependency injection. I find posting events to a bus to be a lot easier to deal with, then dealing with a spaghetti of objects interacting with injected dependencies.
Yes they are?
If it's not referenced it, it's not needed. That's pretty straight forward?
The compiler can tell if something isn't referenced - but it can't tell if a provider that goes into a DI framework is never invoked.
The DI framework can tell (at run-time) that you're asking for something that is missing a provider. It, quite obviously can't tell (at run-time) that you're never going to ask for something in the future.
It sort of can though. It depends on the circumstance. If there is an interface with one implementation or even multiple implementations and that interface isn't referenced anywhere nor are any of its references then you can reason that those dependencies might be provided to the DI container but will never be requested as they can't be. In that case - delete them.
In the case where you have one interface which has multiple implementations and the interface is referenced, I agree. Nothing will tell you if there is one implementation sitting there entirely unused forever.
If you wanted to solve that problem you probably could. In practice I don't find it a big issue.
2. The interface is referenced, the implementations might not even be bound to it, depending on run-time conditions.
Even trivially scoped dependency injection is a fantastic way to make it impossible for your compiler, and very hard for a human, to reason about your dependencies.