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

101–110 of 214 posts

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

#101

Post by FridgeSeal »

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.

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?

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

#102

Post by themarkn »

mehrdadn wrote: post #79
ayroblu wrote: post #48

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…

> 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 makes sense for configs that could ostensibly do this, but that's only a fraction of them. Regardless of what we do about those (if anything), the other ones at least shouldn't be laid out like this.

... “shouldn’t be laid out like this” doesn’t explain why it’s a _problem_ though. I’m curious about this as well. I think it’s fine as is.

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

#103

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

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

#104

Post by mehrdadn »

themarkn wrote: post #102
mehrdadn wrote: post #79

Earlier quoted context omitted.

> 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 makes sense for configs that could ostensibly do this, but that's only a fraction of them. Regardless of what we do about those (if anything), the other ones at least shouldn't be laid out like this.

... “shouldn’t be laid out like this” doesn’t explain why it’s a _problem_ though. I’m curious about this as well. I think it’s fine as is.

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.

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

#105

Post by _ZeD_ »

ksenzee wrote: post #20
tony wrote: post #3

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

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.

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

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

#106

Post by _ZeD_ »

q3k wrote: post #60

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.

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

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

#107

Post by coredog64 »

jjoonathan wrote: post #75
tengbretson wrote: post #56

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.

Systemd pokes its head around the corner. Build tools? Its stomach rumbles. The beast hungers.

So my project will have var/run/.build-unit?

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

#108

Post by overgard »

FridgeSeal wrote: post #101
spanhandler wrote: post #59

Earlier quoted context omitted.

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

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…

I think it's because of C++ in large part. For whatever reason there's been weird conventions in different code bases on how to structure headers vs source (like, put them in the same dir, or have an "includes" and "src" dir that mirror each other, or have an includes dir that doesnt match the src dir at all. Not defending it because it sucks, but I think .NET just inherited that weird interface because its what C++ did.

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

#110

Post by balfirevic »

FridgeSeal wrote: post #101
spanhandler wrote: post #59

Earlier quoted context omitted.

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

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…

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

Post reply on HN