Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The creeping scourge of tooling config files in project root directories

github.com

Post reply on HN
Print view View original

141–150 of 214 posts

Re: The creeping scourge of tooling config files in project root directories

#141

Post by hedora »

tomc1985 wrote: post #114
mehrdadn wrote: post #104

Earlier quoted context omitted.

Same reason why we have subdirectories in the first place and don't just shove everything into one directory. Same reason why you (hopefully) don't put everything on your desk and instead designate places for things, like in drawers. Same reason why we have a ~/.config folder now instead of just shoving everything into ~/ like we used to.

> Same reason why we have a ~/.config folder now instead of just shoving everything into ~/ like we used to. Who/what is the "we" here? Last I checked my homefolder was still chock full of dotfiles in-use.

Now, half of them are in ~/.config This is better because it means you have to look in more places.

Similarly, things also like to hide state in ~/.cache

If they didn’t then rm -rf .appname would restore it to default settings, and we can’t have that.

Re: The creeping scourge of tooling config files in project root directories

#142

Post by HALtheWise »

wwright wrote: post #22
user5994461 wrote: post #15

Earlier quoted context omitted.

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

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 (o…

I strongly recommend https://github.com/jazzband/pip-tools to solve this. It provides a simple script to take a requirements file and "compile" a full specification of all transitive dependencies. You check both files into the repo, point pip at the generated file, and manually modify the other one. It means you often don't need to pin requirements manually at all, and the versions will be explicitly updated whenever you choose to recompile your requirements.

Re: The creeping scourge of tooling config files in project root directories

#143

Post by slimsag »

desert_boi wrote: post #131
dfee wrote: post #96

Earlier quoted context omitted.

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

with ESLint and Prettier on top.

also don't forget:

- .eslintrc.json to configure ESLint

- .prettierignore because it tries to format package-lock.json

- prettier.config.json

- npm/yarn and package.json + node_modules

- .nvmrc to pin your node version

- storybook

- renovate to update dependencies

- .editorconfig to ignore node_modules

- mocha for testing and .mochaarc.js

- stylelint and .stylelintrc.json + .stylelintignore

And maybe throw in Jest, tsconfig.json, a gulpfile, and some other stuff.

Re: The creeping scourge of tooling config files in project root directories

#144

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

Re: The creeping scourge of tooling config files in project root directories

#145

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

Re: The creeping scourge of tooling config files in project root directories

#146

Post by lokedhs »

spanhandler wrote: post #59
sroussey wrote: post #51

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.

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

Like what the Windows file manager does. This is something that absolutely infuriates me every time I use Windows. It's actually difficult to figure out what directory you're actually looking at sometimes because ever the address input bar is lying to you.

Re: The creeping scourge of tooling config files in project root directories

#147

Post by lokedhs »

Jtsummers wrote: post #29
smt88 wrote: post #12

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

*nix systems hide dotfiles by default. Some file browsers may show them. It's been a while since Linux was a daily driver for me, but it would surprise me if any of the standard/common ones showed dotfiles by default. On macOS they're hidden in Finder. I don't know about Windows, I think it shows them by default.

Neither Dolphin nor Nautilus (the file browsers in KDE and GNOME respectively) shows dotfiles by default.

Re: The creeping scourge of tooling config files in project root directories

#149

Post by sergeykish »

kardos wrote: post #84
dahfizz wrote: post #71

Earlier quoted context omitted.

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?

We did? https://fedoraproject.org/wiki/Features/UsrMove

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.

Re: The creeping scourge of tooling config files in project root directories

#150

Post by felbane »

slimsag wrote: post #143
desert_boi wrote: post #131

Earlier quoted context omitted.

with ESLint and Prettier on top.

also don't forget: - .eslintrc.json to configure ESLint - .prettierignore because it tries to format package-lock.json - prettier.config.json - npm/yarn and package.json + node_modules - .nvmrc to pin your node version - storybook - renovate to update dependencies - .editorconfig to ignore node_modules - mocha for testing and .mochaarc.js - stylelint and .stylelintrc.json + .stylelintignore And maybe throw in Jest, t…

Your comment makes me extremely happy that I haven't needed to deal with anything written in Node. This would drive me absolutely bonkers.

Hell, I thought Flask's root directory was getting a bit fluttery with .gitignore, .venv, .flaskenv, __pycache__, and requirements.txt...

Post reply on HN