8 ms·

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 recur

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

ralphstodomingo 6y ago
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.
jeppesen-io 6y ago
A voice of reason
mehrdadn 6y ago
> 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.
- themarkn 6y ago
  ... “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.
  - mehrdadn 6y ago
    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.
    - tomc1985 6y ago
      > 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 6y ago
        [deleted]
      - hedora 6y ago
        Now, half of them are in ~/.config This is better because it means you have to look in more places. 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.
        bmn__ 6y ago
        I notice you chose to exclusively point out the negative aspects.
        tomc1985 6y ago
        https://xkcd.com/927/ https://xkcd.com/927/
    - noskllzgap88 6y ago
      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.
deleted 6y ago
[deleted]
Legogris 6y ago
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...
- tomc1985 6y ago
  Exactly... the problem isn't the proliferation of config files, it's the use of so many tools that require those config files
  - rapnie 6y ago
    So are you advising developers to use less tools, or maybe all-in-one toolsets? Presumably tools are used to support tasks that were otherwise more onerous and time-consuming and maybe neglected because of that.
    - addicted 6y ago
      How about an all in one config file? 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?
      - alephu5 6y ago
        That's how I configure my projects using dhall. 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.
noskllzgap88 6y ago
The problem is someone anthropomorphized their code as “suffering” as justification to debate the color of the bike shed.
sergeykish 6y ago
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?".
ufo 6y ago
I agree it wouldn't make sense to put the configs on a global folder like $HOME/.config but I don't see what would be the problem of putting them on a .config folder at the root of the project directory. Recursive behavior would still work, the same way that Git can recognize that there is a ".git" directory in one of the ancestor directories.
- Terretta 6y ago
  With .config folder at root of project then paths in configs are ../whatever/ instead of whatever/ and ../ is evil plus having ../ on front of every path is noisy.
bryanrasmussen 6y ago
I totally agree with this except - just when I was done with reading this thread I went back to the project I was on and I noticed there was some file in the root of the project red in VSCode so I go look at it, it's a JSConfig.json wtf is that I don't remember that 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 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.
- ralphstodomingo 6y ago
  Yeah - I think that's a cue pointing to you that your understanding of the project at hand may be lacking in some regard. I usually listen to that signal and learn the heck out of the current tooling whose config I see on the root before proceeding with the subdirectories. That feeling of mild anxiety in not knowing why these files are there can be useful, is all I'm saying.
  - bryanrasmussen 6y ago
    yeah or it's a cue that someone using VSCode created a JSConfig.json checked it in and it got pulled by the latest git pull.
hakre 6y ago
Good point, never had a problem to place the configuration files where they belong to, be it in the project root or not, until I figured it out. That's what software configuration management is for, and SCM is obviously in place (given this is a reported issue on Github). 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.
- ayroblu 6y ago
  I disagree with regards to _human readable_ content. We put "README"'s in the project root because it's configuration for most git repo viewer's e.g. GitHub. If GitHub didn't have this auto nice formatting, I probably wouldn't add it, preferring a docs dir (for the general case). Licenses is awkward, it's kinda config too really
  - hakre 6y ago
    Yes, that's why humans can read it on Github. Many people put even ASCII art into it (and restrain from actual HTML tags despite those are just fine in Markdown). So actually no disagreement from my side on that one, at least for me. Your mileage may vary. 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.

ralphstodomingo 6y ago

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.

jeppesen-io 6y ago

A voice of reason

mehrdadn 6y ago

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

themarkn 6y ago
... “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.
- mehrdadn 6y ago
  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.
  - tomc1985 6y ago
    > 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 6y ago
      [deleted]
    - hedora 6y ago
      Now, half of them are in ~/.config This is better because it means you have to look in more places. 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.
      - bmn__ 6y ago
        I notice you chose to exclusively point out the negative aspects.
      - tomc1985 6y ago
        https://xkcd.com/927/ https://xkcd.com/927/
  - noskllzgap88 6y ago
    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.

deleted 6y ago

[deleted]

Legogris 6y ago

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

tomc1985 6y ago
Exactly... the problem isn't the proliferation of config files, it's the use of so many tools that require those config files
- rapnie 6y ago
  So are you advising developers to use less tools, or maybe all-in-one toolsets? Presumably tools are used to support tasks that were otherwise more onerous and time-consuming and maybe neglected because of that.
  - addicted 6y ago
    How about an all in one config file? 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?
    - alephu5 6y ago
      That's how I configure my projects using dhall. 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.

noskllzgap88 6y ago

The problem is someone anthropomorphized their code as “suffering” as justification to debate the color of the bike shed.

sergeykish 6y ago

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?".

ufo 6y ago

I agree it wouldn't make sense to put the configs on a global folder like $HOME/.config but I don't see what would be the problem of putting them on a .config folder at the root of the project directory. Recursive behavior would still work, the same way that Git can recognize that there is a ".git" directory in one of the ancestor directories.

Terretta 6y ago
With .config folder at root of project then paths in configs are ../whatever/ instead of whatever/ and ../ is evil plus having ../ on front of every path is noisy.

bryanrasmussen 6y ago

I totally agree with this except - just when I was done with reading this thread I went back to the project I was on and I noticed there was some file in the root of the project red in VSCode so I go look at it, it's a JSConfig.json wtf is that I don't remember that 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 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.

ralphstodomingo 6y ago
Yeah - I think that's a cue pointing to you that your understanding of the project at hand may be lacking in some regard. I usually listen to that signal and learn the heck out of the current tooling whose config I see on the root before proceeding with the subdirectories. That feeling of mild anxiety in not knowing why these files are there can be useful, is all I'm saying.
- bryanrasmussen 6y ago
  yeah or it's a cue that someone using VSCode created a JSConfig.json checked it in and it got pulled by the latest git pull.

hakre 6y ago

Good point, never had a problem to place the configuration files where they belong to, be it in the project root or not, until I figured it out. That's what software configuration management is for, and SCM is obviously in place (given this is a reported issue on Github). 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.

ayroblu 6y ago
I disagree with regards to _human readable_ content. We put "README"'s in the project root because it's configuration for most git repo viewer's e.g. GitHub. If GitHub didn't have this auto nice formatting, I probably wouldn't add it, preferring a docs dir (for the general case). Licenses is awkward, it's kinda config too really
- hakre 6y ago
  Yes, that's why humans can read it on Github. Many people put even ASCII art into it (and restrain from actual HTML tags despite those are just fine in Markdown). So actually no disagreement from my side on that one, at least for me. Your mileage may vary. 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.