Apologies for being nonspecific, but I don't know how else to describe Bob's struggles. Bob has been on the team for over a year now, and his code is just... not okay.
To his credit, he can make something that works... but that's not enough. His code belongs on programming horror. He's not supposed to be my junior; I'm just the repository's lead. I spend half my week helping him. Reviewing his pull requests takes hours because it's always a rats nest that needs significant refactoring/simplification. I'd love to say "do better" - but this is his best.
Most recently, Bob crashed his dev environment with a getter. (A mix of nested parsing logic with Angular's change detection = CPU crashed). It'd be impressive if it wasn't so irritating since I've already had a conversation with him about proper use of getters/setters. I even demonstrated how spammy the calls can be with a console.log statement for emphasis.
I could go on, but this is enough of a rant. I don't really know how to handle him going forward; I spend so much time helping and teaching him but he retains none of it.
Is there any hope for him? Any learning material? Advice on balancing my own sanity and workload?
That needs strict timeboxing. Because they generally don't "turn things around". Often they've been at the company for decades and everyone just assumes they're doing something right because "why else would they still be here?" They just get shifted from department to department looking for something they're competent at.
What happens is that they just end up a burden on more productive and nice employees. What you see as some sort of welfare I see as "great I have to work with somebody who has no idea what they're doing - and my deliverables depend on this idiot". You can't help everybody. At some point you cut 'em loose.
Granted I don't know the exact situation OP is in - but they need to know that there should be a limit to their willingness to help and train unless it is explicitly their job to do so. And that's okay.