I think the problem isn't the existence of the config files (since they don't change often), but the fact that they take up a disproportionately prominent place

I think the problem isn't the existence of the config files (since they don't change often), but the fact that they take up a disproportionately prominent place in the root directory (since most configure a tool that handles one particular problem that not everyone will have strong opinions about). Having lots of tools is, in some ways a good thing. That's how Unix was designed: have lots of little tools, each designed really well for its job. If you have a problem, and there is a tool for that problem, there's nothing wrong with using the tool to solve the problem. It may come with a learning curve, but what often happens without the tool is you end up evolving your own tool anyway, it's just not as well designed as the industry leader. The problem described on this git issue is generally less of a problem on the Java projects I've worked on, since most of the equivalent configuration ends up in the pom.xml. The JS equivalent problem isn't a problem of too many tools in itself, but rather that no tool in JS has done what Maven has for Java.