For most of these repo-specific config, if you put it in a subdirectory then some tooling won't work properly. If your dockerfile is in ops/, the you have to tell people how to run docker build. If your .eslintrc is in ops/, then those rules will only apply to files in subdirectories of ops/...
Yeah it's certainly tradeoff, especially for the rc-type files that get auto-detected by editors.
Still, I feel like the status quo is pretty good. Most ecosystems have built in task runners for specifying/documenting commands, js and python projects can opt to shove a lot of config in package.json or pyproject.toml for a lot of ecosystem tooling respectively if they want (similar for a lot of languages).
i know this goes down the rabbit hole, but i think every project benefits from a makefile or other taskrunner file. even if a project is a simple “docker build ...” having done task makes it really easy to see
"or other taskrunner file" is the problem, because to some approximation npm or docker are task runners.
The presence of a makefile at the top level tells you you can run make. The presence of a dockerfile tells you you can build with docker. It's not a good system, but it kinda works.
no, a makefile with a docker build task acts as a reference for how to build the image. that’s my point.
_any_ repo has clues about the toolchain encoded in the file types and extensions, but that’s not the same thing.
and yes, npm or yarn can define scripts which can have the same documentation benefits. but there’s lots of others too that are specifically for tasks. i really like https://taskfile.dev.
these files can communicate how to work in a project.
But, can't pretty much any of these be put wherever one wishes? Like `ops/` or w/e?