[deleted]
The creeping scourge of tooling config files in project root directories
91–100 of 214 posts
Re: The creeping scourge of tooling config files in project root directories
#92I 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…
That link is a really good read. Better than TFA, tbh. And also particularly well written
> An interesting side-effect of PEP 518 trying to introduce a standard file that all projects should (eventually) have is that non-build development tools realized they now had a file where they could put their own configuration. I say this is interesting because originally PEP 518 disallowed this, but people chose to ignore this part of the PEP xD We eventually updated the PEP to allow for this use-case since it became obvious people liked the idea of centralizing configuration data in a single file.
Hilarious and indeed interesting
Re: The creeping scourge of tooling config files in project root directories
#93I 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 (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.lockRe: The creeping scourge of tooling config files in project root directories
#94I'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."
Re: The creeping scourge of tooling config files in project root directories
#95I 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…
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...
Re: The creeping scourge of tooling config files in project root directories
#96The 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.
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.
JavaScript isn’t the hero we wanted, but TypeScript is the hero we need.
Re: The creeping scourge of tooling config files in project root directories
#97I 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…
Python is unified on a requirements.txt file with pip, to manage dependencies.
I tried to downvote this, but I think it’s already downvoted to the max. There is so much wrong with this pattern.
Please use something like Poetry to manage deps.
Re: The creeping scourge of tooling config files in project root directories
#98This 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).
Hidden files are never hidden to developers because they need to be accessed and changed so often.
Re: The creeping scourge of tooling config files in project root directories
#99Earlier quoted context omitted.
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.
`ls` is probably the most important place they're hidden, but the Mac OS Finder honors this convention too.
Wow, I've used `ls -la` for so long that I didn't even know the default `ls` behavior. Thanks for reminding me.
Re: The creeping scourge of tooling config files in project root directories
#100I put my noise in an etc/ subdirectory.