Comment by tony | Hacker News Reader

Comment by tony | Hacker News Reader

How conscientious.

And yup, conventions like this work well Linux and BSD's. To note ~/.config for many configs

These days you see this happening inside of .github/, where configs related to gh repos and actions go.

If tooling authors started universally recognizing .config/ as a directory where we could keep stuff, the root could be super clean.

How about just one file, across languages / CI tools / etc? a "project.toml" or "project.yaml" or "project.json"?

    [tool.npm]
    name = "frontend"
    version = "1.0.2"

    [tool.npm.dependencies]
    react = "^16.3.1"

    [tool.travis-ci]
    # ...

    [tool.eslint]
    # ...

    [tool.poetry]
    name = "backend"

    [tool.poetry.dependencies]
    django = "~3.1.0"

If vendors were willing to accept it, it'd be less clutter. Integration tools would only need to check one place (legacy configs would still have to be supported, though, so it's still a dream)

Legacy configs could be ported via YAML / JSON straight into the TOML sections. It'd work for package.json or tslint.json, but not stuff involving runtime, e.g. .eslintrc.js

One directory, maybe .config, seems like a good idea. One file is asking for trouble. All it takes is someone writing their first command-line app mixing up > and >> and suddenly the user's config for every tool they use is gone.

It should be versioned, so it requires a little more effort to be destroyed

But some (most) config belongs in version control, and other parts are environment-specific: perhaps a different path to your database in prod vs development, or instructions for your IDE that may not be to the taste of someone else working on the project with the same IDE.

set -o noclobber

Windows goes a step further with AppData Local and Remote. Which is a good distinction for those of us who like to sync with roaming folder.

Sadly there's a confusing LocalLow and not all apps use AppData anyway. But it's something.

> AppData Local and Remote

I never understood the difference between both. What is it!?

I meant 'Roaming' sorry. And IIRC the roaming is for companies that use network storage or sync to keep people's settings no matter what workstation they use.

I like the idea of a single consolidated config file as long as:

1. It supports real comments (so not json) 2. It supports imports/includes so if it gets unwieldy it can be split up.

Splittig it up so you can also determine the environment. I do this with Django settings the time: base/common, local, testing, production. The latter are very tiny and contain small bits of extra configuration.

Personally I like this approach way more than a bunch of if/else statements in a single file.

Nah, it's far too common for tools to automatically update config files. A unified file would be asking for corruption, lost comments, trivial formatting and ordering changes, and more.

Reply on news.ycombinator.com