This is a UI problem, not a file location problem. GitHub and VS Code (both M$), could implement a nice way of grouping these files out of the of other files at the tip level.
The creeping scourge of tooling config files in project root directories
51–60 of 214 posts
Re: The creeping scourge of tooling config files in project root directories
#52Earlier quoted context omitted.
If everybody had that attitude we'd still be hunting with sticks.
nonsense - files in the root of a directory does not stop progress. What an absurd analogy
I'm guessing it's a tongue and cheek way of saying "why be resistant to change without reason?"
Re: The creeping scourge of tooling config files in project root directories
#53Earlier quoted context omitted.
Python is unified on a requirements.txt file with pip, to manage dependencies.
Not "a" requirements.txt file, sadly. I've seen packages with different requirements for building, installing, and testing. All with their own damned txt file. Oh! And don't forget the duplication in setup.py -- you'll want to put your requirements there, too.
As far as I know, Pip doesn't have the notion of dev dependencies, so you need at least two requirements[.dev].txt files.
Re: The creeping scourge of tooling config files in project root directories
#54I don't get this, what's the problem here? Having config files in root means you know they can apply to all sub directories. This has nice properties like recursive behaviours (see .gitignore) If you want to put (most of) your config files in a .config folder, then most apps should support that If you want to view your config files in a different way, then actually you're trying to solve a different problem. Perhaps…
Likewise here. I think that as far as defaults go, having these config files accessible in project root so makes it easy for people to see what tooling a project uses.
Suppose this pushes through and .config becomes more of a default than a conscious project choice. I don't see all tooling packages to follow-through immediately with it - causing a period where you still have the scourge of some config files in project root, while others are at .config.
Re: The creeping scourge of tooling config files in project root directories
#55Rather than a .config/ folder how bout a .tooling/ folder ... as it is for the tooling. Projects usually have a config dir for server / environment configs. Would be easy to confuse the .config/ of tooling with the config/ for the app itself
Re: The creeping scourge of tooling config files in project root directories
#56The 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.
Re: The creeping scourge of tooling config files in project root directories
#57This is a UI problem, not a file location problem. GitHub and VS Code (both M$), could implement a nice way of grouping these files out of the of other files at the tip level.
This assumes everyone is using GitHub and VS Code - I think the main issue is applying it to the node ecosystem as a whole
Re: The creeping scourge of tooling config files in project root directories
#58The suggestion in the thread to "support defining this in package.json" (https://github.com/nodejs/tooling/issues/79#issuecomment-664...) reminded me of autoconf. It also has the issue of lots of auxiliary files in the project root (but worse since they're not hidden files), and the solution there is that you can add "AC_CONFIG_AUX_DIR(aux)" to the configure.ac to make it look for these auxiliary files in the "aux" subdirectory instead of the project root (for instance, "aux/config.guess" instead of "config.guess").
Re: The creeping scourge of tooling config files in project root directories
#59This is a UI problem, not a file location problem. GitHub and VS Code (both M$), could implement a nice way of grouping these files out of the of other files at the tip level.
Oof, I hate it when an IDE/editor tries to "helpfully" present the file tree differently than it actually is.
Re: The creeping scourge of tooling config files in project root directories
#60To me this is part of a larger problem: tools that expect a given directory layout, or even worse, that they are the sole tenant of a given repository. Just because my project contains some node.js code doesn't mean that I want to have a top-level, global node_modules directory.
Let me organize my repository files however I want and however best fits my project organization.