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...
I’ll admit this is less of a problem in project dirs, since tooling usually confines itself to a single file. But tooling outputs often similarly pollute. For example, I wish Python dumped its artifacts in a single directory I could delete, instead of in every source subdir.
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.
Just like the gitlab-ci.yml, it handles things related to the whole repo, it basically runs a script in the root of the repo anyway.
Sure, supporting other paths is useful (eg. in case of a monorepo), but this default seems sane. Though I'm interested in where others move it, and why.
But nothing is fundamentally wrong either with XDG-esque directory structures.
.config/travis/
.ci/travis/
all the same to me, as long as it's consistent.
Because it defines the project's CICI pipeline? Aka how the project is built, tested, delivered, and deployed?
I mean, that's a more fundament part of the project than which files should be automatically ignored when committing stuff to git (i.e., .gitignore)
git clean has options to only clean ignored files, which generally does what you want. I could see there being weird situations where a file is .PRECIOUS (in make's terms) or where you have a file that's ignored but not a product of the build (a developer-specific config file?) where this doesn't work, but I haven't run into that yet, and it's freeing to not have to maintain a free target by hand.
No, you're the only one arriving at that conclusion.
The whole point is that if you're going to adopt tooling then you'll need to configure them all, and that's fine with config files in the project root tree.
You have a standard JSON config file “.config.json” that resides in the root folder with a global object, with each key containing the config for each tool.
Collisions might be a concern, but you could use the tool’s url as the key so it’s unique. You are already seeing runtimes like Deno and Go do that for importing source code. Couldn’t the same thing apply for this config file as well?
At any rate the closest I could find to this saying was this HN post https://news.ycombinator.com/item?id=8092967 "Configuration files suck. Just use a programming language"
>but you could use the tool’s url as the key so it’s unique.
reminds me of XML namespaces.
on edit: formatting
I'm working on a web application at the moment with a REST API, database, rabbitMQ, a few python workers, nginx, 2 react projects and a Gatsby project plus some docker composes for testing.
Everything is configured in the root file and then this is imported into smaller dhall files in the subprojects. In the build scripts I generate all the yaml and JSON from these, even the docker-composes and it's very ergonomic.
What an awful idea. I don't even know where to start enumerating the problems that this approach creates, and what for? I mean, just think about it. Have you ever had to comb through a config file to add support for something but while you were not sure what option dictated which and what impact this or that option had because documentation is ineffective or awful or even non-existent?
Now multiply that complexity by all the options added by all the tools expected to use a file, compounded by the fact that God knows how many tools also write to that file and may or may not stay in their lane when doing so.
Who in the hell wants to deal with that mess?
And what for? Just because someone wants to adopt a tool but has a problem with having to configure its own config file?
I also don't think that the format matters more than it's use.
Reminds me of some good advice in The Pragmatic Programmer, should be (simple) text-files for editing and (regardless if one or multiple files), a single source of truth (e.g. if multiple files, not the same time the same data to edit in). This is roughly as I remember it and I found it always useful to apply.
If I see duplication, it's about fighting the rot and remove it.
If configuration files are generated, they don't belong under version control (there are some exclusions to this rule, e.g. pinning dependency versions for example when shared with the repository).
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.
It says
{ "compilerOptions": { "baseUrl": "./" }, "exclude": [ "node_modules" ] }
I go google what it is, seems to be some VSCode thing added automatically maybe? https://code.visualstudio.com/docs/languages/jsconfig
but VSCode thinks it should be marked red, something is wrong with this config file I have no familiarity with. grrr.
anyway - I think at some point, especially on projects with lots of devs and lots of tooling, you look at the root and like art you know what you like or don't like and sometimes there will be a feeling that there are just too many files here for configuring stuff! But probably that indicates some other underlying problem, not a problem with having config files in itself.
That feeling of mild anxiety in not knowing why these files are there can be useful, is all I'm saying.
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.
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`.
Who/what is the "we" here? Last I checked my homefolder was still chock full of dotfiles in-use.
Similarly, things also like to hide state in ~/.cache
If they didn’t then rm -rf .appname would restore it to default settings, and we can’t have that.
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.
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.
Recursive behavior would still work, the same way that Git can recognize that there is a ".git" directory in one of the ancestor directories.
And if you allow me to build on the "Finally" note in your comment with a personal note:
Some _human readable_ content belongs into the root as well, e.g. a read-me, information under which conditions the code can be used (copying info) and similar, the important stuff. Otherwise it would mean it only needs to be machine read-able (which can be fine, too, especially for pure configuration management, still though a repository will most likely checked out by a human from time to time).
Uncle Bob raises this question from time to time: When you checkout a repository and look into the tree, what do you see?
The root is always an opportunity to show the projects' birds-view.
Oh what a reminiscence to back then when exchanging software on floppy disks, and when the !readme.txt not written in your language, you found the "link" to the file in your "docs" folder often at the very top.
Or you just found the docs folder, in case no readme there.
Btw., this works on Github, too. The docs folder is normally directly visible above the fold while the read-me might not, especially when there is a long list of files which OP put on topic.
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.