That's one approach, but be careful you don't burn out. I'd also say that tech moves fast enough that you'll need to finetune your approach if you want something to run with for 5 years.
If you want something that'll be good for 5 years look at stacks/technologies that have existed for a little while and are known to be fairly stable/mature, eg everything from jQuery (ubiquitous; embarassed I don't yet know it myself) to Go (newish, but very pragmatic, fewer surprises/less conflict than other offerings, by some margin; on my todo list).
Rust and React are wildly popular in their own ways (they're totally unrelated) but much newer, and I understand they're sufficiently chaotic enough that people can't quite tell if they'll die out next week or stick for the next 5 years, even though they're going incredibly strongly right now.
Most of tech fits into categories like this.
Also, about doing personal projects using arbitrary stacks, that's an excellent idea, but note that the general goal here is learning - I read in a thread on here the other day that building stuff purely to advertise competence is almost never a good idea. A commentator noted that the most you'll get in that case is an "oh, okay, nice" unless your project is relevant to the company (hard) or truly generally unique (really hard). Best case scenario is that a headhunter trawling GitHub notices it.
Hm, now I think about it, it might also be worth it to consider the ramifications of the kind of things you build. If they're things that would gather a small userbase but would be difficult to charge for, maybe think about how "yay I got a job from making this but now I have no time to maintain it" would work out. Handoff? Established GitHub organization you can add other users to? etc. Users remember their customer-service experiences :P