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

161–170 of 214 posts

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

#161

Post by brabel »

I like how Gradle works.

Basically, if you want to add a new "tool" to your project, you add it as a plugin in `build.gradle`:

    plugins {
      id "com.github.spotbugs" version "4.5.0"
    }
Then, in the same file, you configure it:

    spotbugs {
        visitors = [ 'FindSqlInjection', 'SwitchFallthrough' ]
        // more config
    }
Some plugins require external files, but that's usually because the plugin was not designed for Gradle and/or the authors didn't bother to add some code in their plugins to read config from the project file (which is usually very easy).

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

#162

Post by alpaca128 »

spanhandler wrote: post #59
sroussey wrote: post #51

This is a UI problem, not a file location problem. GitHub and VS Code (both M$), could implement a nice way of grouping these files out of the of other files at the tip level.

Oof, I hate it when an IDE/editor tries to "helpfully" present the file tree differently than it actually is.

In my opinion that belongs to the problem category "the software thinks it's smart and tries to simplify something for you".

Some programs try to "correct" your input, some hide or even remove settings so they can't confuse users, some produce all kinds of popups in order to help but only obstructing the view of some information or messing up UI focus in the process, and the list goes on.

This is the best way to make me use other software whenever I have the choice.

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

#163

Post by pm215 »

Legogris wrote: post #129
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…

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

I think there are similarities -- the project's root is the project's, so why does eg the Travis CI system get to insist on having a config file sat in the project root?

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

#164

Post by PudgePacket »

Macha wrote: post #77
wqsz7xn wrote: post #26

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

Thankfully more and more projects are moving to respecting XDG_CONFIG_DIR: The holdouts fall into the following categories: 1. Projects where the author doesn't care but would take a PR. 2. "My tool is super simple and I don't want to complicate it to read env vars or have platform specific config" 3. Projects which value cross platform consistency over consistency with the platform (tmux, though the next version doe…

6. Authors who haven't heard of XDG_CONFIG_DIR.

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

#165

Post by acid__ »

slimsag wrote: post #143
desert_boi wrote: post #131

Earlier quoted context omitted.

with ESLint and Prettier on top.

also don't forget: - .eslintrc.json to configure ESLint - .prettierignore because it tries to format package-lock.json - prettier.config.json - npm/yarn and package.json + node_modules - .nvmrc to pin your node version - storybook - renovate to update dependencies - .editorconfig to ignore node_modules - mocha for testing and .mochaarc.js - stylelint and .stylelintrc.json + .stylelintignore And maybe throw in Jest, t…

Maybe it’s just because I was raised on this ecosystem, but in my opinion the sheer amount of incredible functionality you get from all this tooling (at the low price of $0!) is worth 10-15 set-and-forgot files that don’t even show up when you type ls.

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

#166

Post by kdeldycke »

epistasis wrote: post #2

I 100% agree on this. But it's been pretty hilarious on how obstinate tool makers are about changing to Python's new pyproject.toml [1] Python packaging is a bit of a mess already, so when I recently started a new small package I wanted to choose tooling that would not clutter, but a fair amount of tool makers were reluctant to allow code into their repo that would use the unified toml rather than a ton of separate f…

I love pyproject.toml. I managed to get rid of setup.py, requirements.txt, requirements-dev.txt and MANIFEST.in, and I'm not far from having no setup.cfg soon.

All others stuff (CI/CD workflows, linters, formatters, code of conduct, funding, issue and PR automation, dependency bots, ...) moved to .github.

Now I have a clean and tidy Python project with a tiny 12-items root directory: https://github.com/kdeldycke/meta-package-manager

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

#168

Post by BerislavLopac »

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…

Do you know about the pyclean tool?

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

#169

Post by bryanrasmussen »

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…

I'm pretty sure that I've read an aphorism along the lines that every configuration over time develops into an ad hoc programming language (similar to Greenspun's 10th rule so maybe I am just misremembering https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule)

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

Post reply on HN