Hacker News Reader

Comment by notatoad | Hacker News Reader

I kinda like the status quo. I like seeing all the tooling artifacts at the top level when I open a GitHub repo or something, it’s nice to see at a glance - like a quick digest of what is used to develop that software. And they all are hidden automatically in a local file browser, so it’s not like it’s really a mess. And the .prefix means they don’t mess up tab completion.

It’s the ones that arent hidden that are a problem, and if they’re already obnoxious enough to choose a non-hidden file name they’re probably not going to support a hidden directory either - Dockerfile, Jenkinsfile, and bitbucket-compose.yml, I’m looking at you.

View on HN

> I like seeing all the tooling artifacts at the top level when I open a GitHub repo or something, it’s nice to see at a glance - like a quick digest of what is used to develop that software.

I agree with this proposal that it can be a mess, but hiding the files or directories isn’t a solution. Instead, the mess we often see reflects the abysmal unification of tooling in modern software development, and the JS ecosystem is perhaps the worst offender.

If things suck, let them fester in the open air. Stuffing them away isn’t gonna fix the mess, just sweep it under the rug.

I must say though, that one huge pet peeve that I have, is software that don’t allow projects to be rooted in a subdir of the git repo root. This is a huge annoyance when you work with multiple stacks in the same project.

Alright, so what's the solution, and how do we get there?

I tend to agree. The reason these files land in the root directory of many repos is because the multitude of tools that use them expect their file to be in $PWD, and running make or mvn or docker or npm from the root of the repo is usually convenient. Changing that paradigm needs more of a justification than tidiness, I think.

While I wouldn't put Dockerfile and .rc files in the same category, the hardcoded file convention bugs me.

But, can't pretty much any of these be put wherever one wishes? Like `ops/` or w/e?

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

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.

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 wouldn't mind if some ~/.config-like (https://unix.stackexchange.com/a/33945/203864) convention emerged here similar to the .meta proposal though.

Dockerfiles should support that

Reply on news.ycombinator.com