
The creeping scourge of tooling config files in project root directories - flaque
https://github.com/nodejs/tooling/issues/79
======
ayroblu
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.

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

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

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

~~~
pm215
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?

~~~
pas
Where should it go?

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.

~~~
dijit
it's pretty common to have a .ci folder for your build scripts.

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.

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

.config is probably a better solution than a single top level toml, IMHO, but
far more important is doing something unified rather than continuing the
pollution of the top-level namespace, which merely obscures the project
structure.

[1] [https://snarky.ca/what-the-heck-is-pyproject-
toml/](https://snarky.ca/what-the-heck-is-pyproject-toml/)

~~~
user5994461
Python is unified on a requirements.txt file with pip, to manage dependencies.

~~~
wwright
requirements.txt has a lot of deficiencies for package management (compare to
the various features Yarn or Cargo offer). The biggest weakness is transitive
dependency locking: even if you specify the exact version of the dependencies
you want, Pip can still resolve to a different version of _their_
dependencies, and even then there’s no verification that the content matches
what is expected beyond the version number (other tools use a content
checksum). This can cause a long tail of reproducibility and maintenance
issues.

It’s also a tiny subset of what the parent describes.

~~~
gruez
>The biggest weakness is transitive dependency locking: even if you specify
the exact version of the dependencies you want, Pip can still resolve to a
different version of their dependencies

Isn't that what pip freeze is for?

~~~
lmm
The trouble there is that if you freeze you can't unfreeze. A project needs
the equivalent of both gemfile and gemfile.lock (unless you're using a system
like maven that got things right the first time), but there's no standard way
of having both of them in Python.

------
tengbretson
The amount of pressure you feel telling you you are using too many tools
should scale linearly with the number of tools you use. This discomfort you
feel with seeing all of those config files is telling you something. Use fewer
tools.

~~~
jolux
I tend to see a glut of tooling as a sign that a language has serious design
flaws, as most important things should be done by the compiler, but I’d rather
have JavaScript with proper tooling and types than nothing at all.

~~~
dfee
JavaScript isn’t the hero we wanted, but TypeScript is the hero we need.

~~~
vorpalhex
JS is a great language for it's intended purposes but I still can't get
onboard the TS train. Adding types post-hoc has never improved a codebase that
I've seen but it has caused a lot more bad patterns to show up.

Simplicity is a virtue (at least sometimes).

~~~
rumanator
> JS is a great language for it's intended purposes

Which part of JS, as a programming language, do you see as great or even
adequate when compared with contemporary programming languages?

> Adding types post-hoc has never improved a codebase that I've seen but it
> has caused a lot more bad patterns to show up.

That assertion makes no sense. I mean, all TypeScript does is impose arbitrary
sanity checks on a programming language which is plagued for not having any.
Where do you interpret the addition of sanity checks as a source of problems?

------
rswail
I'm not sure why this [1] pattern can't be adopted/extended. Put everything in
a .config directory.

Search path for config is:

* /etc/config

* $XDG_CONFIG_HOME (~/.config)

* $PROJECT_CONFIG ($PROJECT_ROOT/.config)

* directories between $PROJECT_ROOT and $CWD for .config

* $CWD/.config

This allows for system wide, then user wide, then project wide, then directory
hierarchy configs, with lower levels overriding higher ones.

Inside .config, each tool can have it's own chosen file, directory, extensions
directory, so:

 _.config_ /$TOOL.{json,yaml,toml,ini,xyz}

 _.config_ /$TOOL/config. _ext_

 _.config_ /$TOOL.d/ _modular config files_ eg 00-module. _ext_

Most of the time for most projects, there will be system wide and user wide
config, then a project wide config. Overrides lower in the hierarchy tend to
be less used.

Yes, it means that there's a tree search for a tool to get its final config.
Whether that's a real issue for performance or otherwise is a potential to
remove some of the hierarchy/search.

[1] [https://specifications.freedesktop.org/basedir-
spec/basedir-...](https://specifications.freedesktop.org/basedir-spec/basedir-
spec-latest.html)

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

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

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

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

------
silviogutierrez
I think ultimately it comes down to personalities. I'm the kind of person that
likes directories and folders. And having top level files feels clunky and
disorganized. Like much organization, taken to the extreme it can be a form of
procrastination to avoid doing real work. Yak shaving, if you will.

But opening the root project folder to just a list of subfolders gives me a
very nice first impression.

Below is my list of config files for
[https://www.joyapp.com](https://www.joyapp.com) (Django + NodeJS). Not a
hugely complex architecture, mind you.

Some notes: _.editorconfig_ at least tries to consolidate this for some
things. And _pyproject.toml_ could help with Python. Still, definitely jarring
and something I've noticed.

    
    
        .coveragerc
    
        .dockerignore
    
        .editorconfig
    
        .flake8
    
        .gitattributes
    
        .gitignore
    
        .isort.cfg
    
        .prettierrc
    
        .shellcheckrc
    
        jest.config.js
    
        mypy.ini
    
        package.json
    
        pytest.ini
    
        requirements.txt
    
        shell.nix
    
        tsconfig.json
    
        tslint.json
    
        webpack.config.ts
    
        yarn.lock

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

~~~
Macha
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 does budge a little)

4\. Projects which consider XDG as just "some desktop Linux thing" and don't
consider themselves as caring about desktop that much or just that they
predate XDG (SSH)

5\. Projects who mix runtime and config and cached data in a single directory
and don't want to split them out for proper XDG support.

The ArchWiki probably has the best centralised tracking of attempts to get XDG
support implemented:
[https://wiki.archlinux.org/index.php/XDG_Base_Directory](https://wiki.archlinux.org/index.php/XDG_Base_Directory)

~~~
PudgePacket
6\. Authors who haven't heard of XDG_CONFIG_DIR.

------
Izkata
Ehh, this is just moving the mess from one location to another. All these
config files can be grouped into two or three conceptual things:

* Dependencies - Things required for your code to run, for example Dockerfile, package.json, yarn.lock

* Metrics - Measuring code quality, but the project works without these, such as jest.config.js, .eslintrc, .eslintignore

* Other - I don't recognize several config files here, and suspect some don't fall into the categories above, but am not sure. Also, README.md and .gitignore would fall into this category, but probably ought to remain at the top.

So instead of a generic "configs/" directory, if I was to organize these
myself, I'd probably want at least two subdirectories so it would, y'know,
actually be a bit more organized.

------
q3k
To me this is part of a larger problem: tools that expect a given directory
layout, or even worse, that they are the sole tenant of a given repository.
Just because my project contains some node.js code doesn't mean that I want to
have a top-level, global node_modules directory.

Let me organize my repository files however I want and however best fits my
project organization.

~~~
_ZeD_
No please. Standardization is the key. You (not you!) Don't know how to
organize your project, and I don't want to know where are the config in each
project I work on

~~~
reillyse
this is the solution :) ... I miss rails where everyone knew where everything
was supposed to go, a little like how much I love prettier now - no more
stupid bike shedding conversations about coding style.

------
Trisell
I don’t find it a scourge. I actually find that I can look quickly at a
project and get an idea of the tools that they are using. This seems to be a
bonus and really a few more files isn’t a big deal.

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

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

~~~
FridgeSeal
Looks pointedly at Visual Studio.

Few pieces of development-related software frustrate me more than Visual
studio.

The seeming disconnect between what's on disk, where on disk it is, and where
and how it's displayed in the UI is cavernous. It also outright ignore things
that are present in the folder unless you explicitly add it through the
interface. God forbid you drop a file in, add it through the UI then move it
because you discover you've dropped it into the wrong one of the 3 million
nested folders large dotnet projects seem to generate.

Changing things on disk underneath it practically gives it an aneurysm. VSCode
and IntelliJ IDE's handle the same situations without panicking, so why is VS
so fragile?

~~~
balfirevic
> The seeming disconnect between what's on disk, where on disk it is, and
> where and how it's displayed in the UI is cavernous. It also outright ignore
> things that are present in the folder unless you explicitly add it through
> the interface. God forbid you drop a file in, add it through the UI then
> move it because you discover you've dropped it into the wrong one of the 3
> million nested folders large dotnet projects seem to generate.

This is no longer the case for "new style" VS project files (used by default
on .Net Core projects). It works sanely now.

------
ocdtrekkie
I feel like a given tool deserves at best a single item in the root directory.
If your tool needs more than one, you should be making a folder. I'd be
totally on board with putting all those folders in another folder, but I'm
iffy on the indeed the frustration of getting everyone to agree on one.

------
neurostimulant
My head hurt thinking about how much efforts and coordination across multiple
ecosystems required to pull it off. And if they do manage to pull it off, the
reward is... slightly cleaner project top directory?

------
johnwalkr
Fully agreed but if everything is in one folder out of the it doesn’t need to
be hidden anymore, it could be “config” instead of “.config”. Maybe even
“config” (project config inside version control) and “.user-config” (project
config by developer not inside version control). The issue hints at this but
deliberately descopes user configs. Files inside the folders could have a dot
depending on if they are normally edited throughout development or normally
left alone.

------
CivBase
It's not a scourge. It's a sensible default location. Most tools let you
explicitely specify a config file path if you want to store it elsewhere.

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

~~~
smt88
On which systems are they hidden? I hadn't even considered this issue because
no file browser I've used in the last ~10 years has hidden dotfiles. Maybe
Windows Explorer does, but that's a setting I typically change right away, so
I don't even remember.

~~~
tesseract
`ls` is probably the most important place they're hidden, but the Mac OS
Finder honors this convention too.

~~~
dylan604
i much prefer them to be hidden by default. i know they are there, but rarely
do i need them. especially in something like `for i in $(ls -1)` type of
commands. if i need them `alias 'lla = ls -la'`, 'alias 'la = ls -a'` are
faves to now see what i'm looking for quickly

~~~
Symbiote

      for i in *

------
javajosh
I mean, for most tools it would be pretty easy to look at .config/ first and
then at the project root - and print something about the new best practice.

The whole thing is a little uncomfortable though. There is a clear isomorphism
between the contents of the structure of, say, a JSON file, and the contents
of a directory of structured text files (and other directories). Heck, you
could build a little tool with a slider that moves all the data between a
single file, and a deep directory hierarchy with lots of tiny text files as
the leaves.

Personally I feel like the best solution is to somehow "indelibly" combine the
tool with its config within a project, _de facto_ removing all config options
from the developer. In the worst case, it could be something as silly as a
wrapper script with config embedded in there. Of course this is a kind of
fiction, but a useful one. It feels nice to get to a point where you don't
have to think about tooling. (The last time for me was like 2000).

~~~
akira2501
> In the worst case, it could be something as silly as a wrapper script with
> config embedded in there.

That's not a terrible idea. For me, I really like tools such as 'nft' that
take advantage of the shebang line to solve more or less this exact problem.

------
didip
This is a non-issue, thus no need for a solution.

If you have too many config files, then you should use less tools.

Besides, most of them are already hidden anyway (because of dotfiles).

~~~
Polylactic_acid
Hidden files are never hidden to developers because they need to be accessed
and changed so often.

------
thenanyu
This is fine. It's practical, but a little ugly. Same discussion that we had
the other day with Tailwind CSS. It's fine, it's very practical, but a little
ugly.

------
devin
Who cares? The obsession with hierarchy is silly. Good search beats hierarchy.

~~~
lolsal
Not if you don't know what you're looking for (i.e. just browsing).

------
skocznymroczny
I think a good fix would be hiding dotfiles on repository view like on GitHub.
"ls" hides dotfiles from you by default, so why shouldn't GitHub. You can
always add a checkbox "Show hidden files" or instead of completely hiding them
put them in an accordion (12 hidden files) that people can click to reveal
them.

------
sethammons
I'm not a node dev, but our projects at work keep growing with helper files.
We have a .buildkite to control the build, we have a makefile, a Dockerfile, a
docker-compose file, go.mod and go.sum. These core files are about half of
what we had a few years ago, so that is nice. The makefile references a dozen
helper scripts though that are also checked into the repo (helpers to run
tests, build images, publish images, clean up, etc). Most of these are vastly
similar between different repos/services we run. I can't think of something
better, and there is a part of me that enjoys the lack of magic: just follow
the code starting at ./buildkite which will point to each make operation which
will point to each helper script. The other part of me feels like, "I just
want to write some code and as long as my project is structured right,
everything else should be shared tooling _outside_ my repo."

------
tlb
It's probably too late to change every tool.

If the main problem is that, when you go look at a project on github or
gitlab, you see a long list of config files rather than the code you're
looking for, a cleaner solution is for the git sites to show the listing for a
/src directory instead of / on the project page.

~~~
gerry_shaw
Or hide/collapse dotfiles like the ls command does.

~~~
mikepurvis
Putting them in .config is something to work toward in the long term, but I
like this as an immediate fix. A possible UX could be a single entry at the
bottom of the repo root listing with "\+ 6 hidden files, click here to show",
that then expands out to to reveal the full listing when clicked.

Edit to add— someone suggests this on the linked issue, and it is mentioned as
a concern that auto-hiding the files could lead to them being used to conceal
malicious code. Not sure how significant of a concern that really is, but it's
an interesting angle, anyway.

~~~
Symbiote
You can also hide malicious code by putting it in a subdirectory, so I don't
agree with their concern.

------
sneak
The root is the right place for project-wide settings.

GitHub and other tools should do what ls does and hide dotfiles by default.
That’s _why_ they are dotfiles.

Other project-unrelated config/metadata should follow the .git example and use
dotfile config files, preferably yaml or something similar (not json, as it
does not support comments).

~~~
Symbiote
Another option would be for Github etc to sort dotfiles to the bottom of the
listing.

------
cesarb
The suggestion in the thread to "support defining this in package.json"
([https://github.com/nodejs/tooling/issues/79#issuecomment-664...](https://github.com/nodejs/tooling/issues/79#issuecomment-664471262))
reminded me of autoconf. It also has the issue of lots of auxiliary files in
the project root (but worse since they're not hidden files), and the solution
there is that you can add "AC_CONFIG_AUX_DIR(aux)" to the configure.ac to make
it look for these auxiliary files in the "aux" subdirectory instead of the
project root (for instance, "aux/config.guess" instead of "config.guess").

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

------
nautilus12
I feel like the is just unecessary OCD behavior. We get enough of that in
software already

------
throw_m239339
The good old "conventions" vs "configuration" debate. Seems like Javascript
looks more and more like Java with all these manifests.

Though XML solved the issue of needing multiple config files long ago, with
namespaces.

~~~
hnzix
Now we just need to finish moving from REST to pseudo-RPC and we'll have come
full circle back to the 90s. Does this mean I can put bevels on my UI buttons
again?

~~~
rndgermandude
*gRPC ;)

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

------
bfred_it
There’s a solution to this problem: [https://github.com/sindresorhus/hide-
files-on-github](https://github.com/sindresorhus/hide-files-on-github)

Additionally, your OS probably already natively hides files that start with a
dot, so this is just a UI problem.

Please don’t “solve” this issue by moving files to a sub-directory. If
anything, only leave non-config files there, it’s the obvious simple solution
that most projects follow anyway.

------
DivisionSol
This is a problem I've encountered on my projects. I just want to nestle them
all in a `config/` folder. Alas, lots of the tools really dislike if you would
like a configuration in a spot other than the root directory. Suddenly you get
to enjoy debugging all the times some functionality wants to be relative to
the config directory instead.

I love the idea of a standard config file, but... Cross-project
standardization in the JS ecosystem? Unlikely.

------
scrose
The Rails community attempted to do something like this with the introduction
of Webpacker in Rails 5. They backtracked after a few months. Most likely
after realizing how many thousands of npm packages make tightly coupled
assumptions to the location of things like ‘package.json’ and the amount of
patches it would require.

------
smt88
In the screenshot in the article, 5 out of 8 are related to using JavaScript.
Anecdotally, it does seem like more of a problem with Docker + JavaScript +
Git in the same project.

I know some tools allow you to specify the location of your config files, and
it would be nice if all tools started to do that.

~~~
kahrensdd
It looks like the issue was opened against the tooling project of nodejs, so
perhaps the author is trying to start with JavaScript. It is incredible how
many of these files you get in a basic Node or React app however.

------
hakcermani
Rather than a .config/ folder how bout a .tooling/ folder ... as it is for the
tooling. Projects usually have a config dir for server / environment configs.
Would be easy to confuse the .config/ of tooling with the config/ for the app
itself

------
dgellow
I would assume all these tools to support a —-config or —-file parameter to
specify where my config is. Couldn’t that be specified in package.json
directly? That way you can move your config wherever you want.

------
chmod775
This is a problem mainly for people who use GUIs.

When you use a terminal you don't really care how many files are in a
directory, unless they have names that are annoying to autocomplete.

~~~
epistasis
If that were the case, why would we bother separating out code into multiple
directories at all?

The reason we bother with modules and directories is to help organize code and
ease discovery. And whether we use ls or a GUI, we all start out the process
of discovery with a directory listing.

The top-level directory, where these files are, is often where there's the
most flexibility in terms of how to lay out things. All this clutter hides the
project organization and makes it difficult to discover what's going on. It
was one thing when it was just autotools, but the proliferation of tools in
the last decade has brought it over a tipping point, IMHO.

~~~
chmod775
>If that were the case

It is the case: They don't bother me when I'm using a CLI, but when I use
Visual Studio Code for instance, all those files are annoying when I'm looking
for something/scrolling past them.

------
mcovey
This is not a new problem. You should see my home folder. I hardly ever look
at it, I moved into ~/Downloads since at least I can keep that tidy myself.

------
MrQuincle
Interesting discussion.

If it's about "cleaning up" before committing, a single script that moves
files back and forth from project root to a .config path might also be an
option...

------
edoceo
I'm using .config when I find it but for the last 15+ years on new projects,
regardless of language I'd been making an `etc` directory and putting config
in there.

------
LoSboccacc
what's the difference between /tool.cfg and /tool/tool.cfg?

if your project is a hodgepodge of tooling the problem is the hodgepodge of
tooling in your project, maybe you need to nest modules or to split libraries,
instead of changing everyone else sane defaults because modern hip toolchains
can't handle dependents and nested subprojects without stepping on each other
toes or requiring the full lib in a single place

------
juped
The great thing about all these config files is as a barometer for the
popularity of various bad flavor-of-the-month config file formats reinventing
key=value.

------
jchook
I find many developers have an aversion to directories containing many files,
even if those files semantically “belong there“.

I think our tools drive this aversion quite a bit.

------
mbar84
A nice convention in python projects is that you can use setup.cfg or
pyproject.toml for many tools and they each just use their particular section.

------
tylerjwilk00
Simple. Add a new config to the project root directory that defines the config
locations. Done. /jk

I do like the .config directory naming suggestion though.

------
gumby
This is not what unexpected!

To me the scourge is tool config files being in the repo at all.

Ok I’ll make an exception for .gitignore or something that enforces house
style or formatting conventions to make things proper for check in.

But an editor config? That’s so user-specific and shouldn’t affect (or should
I say “infect”) the _source code_.

~~~
iainmerrick
The .editorconfig specifies things like tabs vs spaces and the indent size.
Everybody needs to use the same settings to avoid messing up the formatting
every time they edit a file. Therefore, .editorconfig gets checked in so that
everybody gets the same settings.

------
smitty1e
I put my noise in an etc/ subdirectory.

------
badrabbit
How come /usr/etc/ didn't become popular?

~~~
dahfizz
What's the advantage over plain old /etc ? I am always annoyed by /bin,
/usr/bin, /usr/share/bin, and others. Why can't we consolidate?

~~~
kardos
We did?

[https://fedoraproject.org/wiki/Features/UsrMove](https://fedoraproject.org/wiki/Features/UsrMove)

~~~
sergeykish
I always wondered why /usr was not abandoned in favor of root

> Why don’t you move all /usr contents to / and forget about /usr?

> Because this introduces a lot of new toplevel directories, which all have to
> be mount points then to be shared across other hosts.

> Ok, but what about a root filesystem on the network and mounting local
> filesystems only?

> Then you would share the toplevel directory hierarchy among all hosts. Hosts
> would need to mount /etc and /var for host-only versions.

So it is about network boot. Sad. There is nothing "usr" about /usr, it is
system installed packages - /sys or /System. And /usr is for "/usr/dmr" which
is /home. At least no more /usr/local.

------
29athrowaway
I also personally think it sucks.

Put everything in a folder, and use a namespace, e.g.:

    
    
        org.organization-name.project.json

~~~
dylan604
namespaces was the thing i was looking for without knowing what it was. it was
a very happy day in my world when i was introduced to them.

