Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The creeping scourge of tooling config files in project root directories

github.com

Post reply on HN
Print view View original

121–130 of 214 posts

Re: The creeping scourge of tooling config files in project root directories

#121

Post by jrumbut »

themarkn wrote: post #102
mehrdadn wrote: post #79

Earlier quoted context omitted.

> I 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 makes sense for configs that could ostensibly do this, but that's only a fraction of them. Regardless of what we do about those (if anything), the other ones at least shouldn't be laid out like this.

... “shouldn’t be laid out like this” doesn’t explain why it’s a _problem_ though. I’m curious about this as well. I think it’s fine as is.

I think it's the varying degrees of importance and surprise factor.

One dotfile has the maintainer's eccentric syntax highlighting preferences, another has critical build system settings needed to make any use of the code. Which ones do I really need to knand which are just conveniences for users of a particular IDE?

There are very few pieces of information where, to me, the natural place to look for it is "a dotfile at the root of the project." gitignore is an exception here.

Re: The creeping scourge of tooling config files in project root directories

#122

Post by noskllzgap88 »

mehrdadn wrote: post #104
themarkn wrote: post #102

Earlier quoted context omitted.

... “shouldn’t be laid out like this” doesn’t explain why it’s a _problem_ though. I’m curious about this as well. I think it’s fine as is.

Same reason why we have subdirectories in the first place and don't just shove everything into one directory. Same reason why you (hopefully) don't put everything on your desk and instead designate places for things, like in drawers. Same reason why we have a ~/.config folder now instead of just shoving everything into ~/ like we used to.

So copy them in there after you clone it?

This is the sort of issue that leads to “this page intentionally blank” type use of resources.

“When everything is a hammer...” when all you have to work with is a file system it always looks messy.

I’m more interested in making sure the right values exist in memory for runtime use.

Source, config, and comments could all live in one file and be specially delimited for look up too.

It’s all arbitrary at that point. This is really focusing on the wrong issues in computing.

Re: The creeping scourge of tooling config files in project root directories

#123

Post by Izkata »

Ehh, this is just moving the mess from one location to another. All these config files can be grouped into two or three conceptual things:

* Dependencies - Things required for your code to run, for example Dockerfile, package.json, yarn.lock

* Metrics - Measuring code quality, but the project works without these, such as jest.config.js, .eslintrc, .eslintignore

* Other - I don't recognize several config files here, and suspect some don't fall into the categories above, but am not sure. Also, README.md and .gitignore would fall into this category, but probably ought to remain at the top.

So instead of a generic "configs/" directory, if I was to organize these myself, I'd probably want at least two subdirectories so it would, y'know, actually be a bit more organized.

Re: The creeping scourge of tooling config files in project root directories

#124

Post by [deleted] »

tomc1985 wrote: post #114
mehrdadn wrote: post #104

Earlier quoted context omitted.

Same reason why we have subdirectories in the first place and don't just shove everything into one directory. Same reason why you (hopefully) don't put everything on your desk and instead designate places for things, like in drawers. Same reason why we have a ~/.config folder now instead of just shoving everything into ~/ like we used to.

> Same reason why we have a ~/.config folder now instead of just shoving everything into ~/ like we used to. Who/what is the "we" here? Last I checked my homefolder was still chock full of dotfiles in-use.

[deleted]

Re: The creeping scourge of tooling config files in project root directories

#125

Post by wombatpm »

smohare wrote: post #120
Legogris wrote: post #95

Earlier 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...

The same argument is made for not adhering to the XDG spec for user configuration files. The result is you have no real sense of specific locations for config files, shared static data, and app-generated data. If an app follows the spec you know exactly where to look. Otherwise it’s anyone’s guess. I’ll admit this is less of a problem in project dirs, since tooling usually confines itself to a single file. But toolin…

With 3.8 python has PYthoncacheprefix where you can specify where the pyc files end up. Makes life so much better with docker

Re: The creeping scourge of tooling config files in project root directories

#126

Post by chii »

throw_m239339 wrote: post #112

The good old "conventions" vs "configuration" debate. Seems like Javascript looks more and more like Java with all these manifests. Though XML solved the issue of needing multiple config files long ago, with namespaces.

javascript ecosystem is just slowly (and badly) reinventing all of the "enterprise" features that they claim to hate about java!

Re: The creeping scourge of tooling config files in project root directories

#127

Post by sergeykish »

ayroblu wrote: post #48

I 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…

That's syntax war, the least useful aspect of programming with strong opinion from every party. And next time there would be "why every language has different config folder?".

Re: The creeping scourge of tooling config files in project root directories

#128

Post by sergeykish »

mehrdadn wrote: post #104
themarkn wrote: post #102

Earlier quoted context omitted.

... “shouldn’t be laid out like this” doesn’t explain why it’s a _problem_ though. I’m curious about this as well. I think it’s fine as is.

Same reason why we have subdirectories in the first place and don't just shove everything into one directory. Same reason why you (hopefully) don't put everything on your desk and instead designate places for things, like in drawers. Same reason why we have a ~/.config folder now instead of just shoving everything into ~/ like we used to.

There is no One True Place, would you like drawers with my preferences and no way to override?

The list of configuration files/directories is known. Why can't those who bother present them as they desire? Instead of forcing their will on others.

There reason for ~/.config is separation from data and cache. And the reason behind XDG Base Directory Specification is a generic way to run application with another config `XDG_DATA_HOME=foo bar`.

Re: The creeping scourge of tooling config files in project root directories

#129

Post by Legogris »

smohare wrote: post #120
Legogris wrote: post #95

Earlier 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...

The same argument is made for not adhering to the XDG spec for user configuration files. The result is you have no real sense of specific locations for config files, shared static data, and app-generated data. If an app follows the spec you know exactly where to look. Otherwise it’s anyone’s guess. I’ll admit this is less of a problem in project dirs, since tooling usually confines itself to a single file. But toolin…

> The same argument is made for not adhering to the XDG spec for user configuration files

I think it's a fundamental difference in that the project repo should be self-contained and "owned", whereas arbitrary software I run really shouldn't be putting files in my home directory.

In a software repo, anything inside it belongs to the project.

Post reply on HN