I would assume all these tools to support a —-config or —-file parameter to specify where my config is. Couldn’t that be specified in package.json directly? That way you can move your config wherever you want.
The creeping scourge of tooling config files in project root directories
41–50 of 214 posts
Re: The creeping scourge of tooling config files in project root directories
#42Earlier quoted context omitted.
On which systems are they hidden? I hadn't even considered this issue because no file browser I've used in the last ~10 years has hidden dotfiles. Maybe Windows Explorer does, but that's a setting I typically change right away, so I don't even remember.
`ls` is probably the most important place they're hidden, but the Mac OS Finder honors this convention too.
I think Windows has them hidden by default as well (in explorer).
Re: The creeping scourge of tooling config files in project root directories
#43How come /usr/etc/ didn't become popular?
Re: The creeping scourge of tooling config files in project root directories
#44Who cares. Get over it.
I'm sure your bosses love you.
Boss: Where's the config file?
You: In the project root.
Boss: Where's the include with the methods for this part?
You: Loose in the project root.
Boss: Where's the viewer?
You: Right next to the other file in the project root.
Boss: @#!$%^&
Re: The creeping scourge of tooling config files in project root directories
#45I also personally think it sucks. Put everything in a folder, and use a namespace, e.g.: org.organization-name.project.json
namespaces was the thing i was looking for without knowing what it was. it was a very happy day in my world when i was introduced to them.
Re: The creeping scourge of tooling config files in project root directories
#46[deleted]
Re: The creeping scourge of tooling config files in project root directories
#47How come /usr/etc/ didn't become popular?
This is for config files inside a repo.
Re: The creeping scourge of tooling config files in project root directories
#48I 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 hide show toggling or automatic grouping (see macOS desktop stacks) with your fs viewer would be a better area to tackle.
Finally, just wanted to say, everything at root level is usually config or a folder, so if I want to understand what tooling a project uses, I know immediately where to go, code is always in a "src" or similar. It sounds like this is a feature, not a bug.
Re: The creeping scourge of tooling config files in project root directories
#49On another note can we talk about the amount of projects that just dump their config/log files in the root directory as a 'hidden' file when you start them? Why? we have a .config for a reason.
Do you mean the system-level config folder? Won't that cause problems when A) you rename / move a folder or B) copy a folder to a different computer?
Nope, he means the "new" LSB preferred directory for user-level configurations. "New" being quoted here because it's around a decade old already.
Re: The creeping scourge of tooling config files in project root directories
#50I feel like a given tool deserves at best a single item in the root directory. If your tool needs more than one, you should be making a folder. I'd be totally on board with putting all those folders in another folder, but I'm iffy on the indeed the frustration of getting everyone to agree on one.