Earlier quoted context omitted.
I tend to see a glut of tooling as a sign that a language has serious design flaws, as most important things should be done by the compiler, but I’d rather have JavaScript with proper tooling and types than nothing at all.
JavaScript isn’t the hero we wanted, but TypeScript is the hero we need.
The creeping scourge of tooling config files in project root directories
131–140 of 214 posts
Re: The creeping scourge of tooling config files in project root directories
#132Additionally, your OS probably already natively hides files that start with a dot, so this is just a UI problem.
Please don’t “solve” this issue by moving files to a sub-directory. If anything, only leave non-config files there, it’s the obvious simple solution that most projects follow anyway.
Re: The creeping scourge of tooling config files in project root directories
#133The amount of pressure you feel telling you you are using too many tools should scale linearly with the number of tools you use. This discomfort you feel with seeing all of those config files is telling you something. Use fewer tools.
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.
Re: The creeping scourge of tooling config files in project root directories
#134How come /usr/etc/ didn't become popular?
What's the advantage over plain old /etc ? I am always annoyed by /bin, /usr/bin, /usr/share/bin, and others. Why can't we consolidate?
Re: The creeping scourge of tooling config files in project root directories
#135Also, please don't use dotfiles. There is no reason to hide such important files.
Re: The creeping scourge of tooling config files in project root directories
#136Re: The creeping scourge of tooling config files in project root directories
#137Earlier quoted context omitted.
Yeah, I take a cluttered root dir over having to hunt down files I may not know exist in various places in order to fully understand a project I’m not the maintainer of. Gets me every time when a maintainer puts Dockerfile in some random subdirectory. If the root dir is full of dozens of files from all the tooling needed to build your software, maybe you have another problem than directory structure...
Exactly... the problem isn't the proliferation of config files, it's the use of so many tools that require those config files
Re: The creeping scourge of tooling config files in project root directories
#138The amount of pressure you feel telling you you are using too many tools should scale linearly with the number of tools you use. This discomfort you feel with seeing all of those config files is telling you something. Use fewer tools.
There's lots to complain about in JavaScript land but IMO having a bunch of config files in the root is a feature, not a bug.