[joesmo]

I don't see how this reduces dependencies on any specific framework or in any way affects that at all. I'm the one who chooses what dependencies and frameworks I work with. The only way these tools affect which dependencies I choose is that they limit the ones that can work with each other. Nor does it "avoid using big one-size-fits-all monoliths," because that wasn't a problem I had in the first place. The article is about build tools in case you haven't noticed.

It does not let me choose the right tool for the job. That's exactly what I'm describing in the post. It forces you to use whatever the authors of library X thought is the right tool for the job. And the authors of library Y and the authors of library Z ... etc. to the point where it becomes impossible to actually work with libraries from different sources together unless you manually manage them.

It does not make the team a lot more rounded to learn and understand a bunch of build tools that do the same thing as each other. What would make it more rounded is if these tools weren't so shitty, worked together, and there was only one of them so they could focus on actually building stuff instead of mentally masturbating about stupid build tools that don't work.