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

191–200 of 214 posts

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

#191

Post by mauvehaus »

BerislavLopac wrote: post #168
smohare wrote: post #120

Earlier quoted context omitted.

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…

Do you know about the pyclean tool?

Since switching to git, I'm increasingly of the mind that clean) belongs to the source control (`git clean') rather than the build. After all, the source control knows what files belong to a bare checkout of the project and which have shown up since you got your grubby little paws on the code!

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.

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

#193

Post by hakre »

addicted wrote: post #151
rapnie wrote: post #137

Earlier quoted context omitted.

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.

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…

Not so sure if it "must" be _one_ 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).

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

#194

Post by account42 »

dahfizz wrote: post #62
emmelaich wrote: post #11

Also, please don't use dotfiles. There is no reason to hide such important files.

It's nothing to do with importance and everything to do with how often you need to see and access the file. My .vimrc and .bashrc are super important, but I rarely need to edit them and I never need to be reminded of their existence, so having them show up every time I ran ls in home would be annoying.

Both of these should ideally not be in the home directory at all but under XDG_CONFIG_HOME.

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

#195

Post by bryanrasmussen »

ralphstodomingo wrote: post #189
bryanrasmussen wrote: post #184

Earlier quoted context omitted.

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

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.

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.

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

#196

Post by ayroblu »

hakre wrote: post #188
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…

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

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

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

#197

Post by peterwwillis »

If the organization of files in your repo is your biggest problem, you've obviously got excellent code and no tech debt.

In which case you probably have enough free time to build a tool that just moves files around at runtime. Organize your repo however you want, then run your tool as a wrapper for any other command, and it'll move all files into the places other tools expect them. Now you've solved the problem, which was that humans like aesthetically pleasing things that serve no useful purpose.

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

#198

Post by hakre »

ayroblu wrote: post #196
hakre wrote: post #188

Earlier quoted context omitted.

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

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

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.

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

#199

Post by ufo »

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…

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.

Post reply on HN