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

201–210 of 214 posts

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

#201

Post by epistasis »

chmod775 wrote: post #200

This is a problem mainly for people who use GUIs. When you use a terminal you don't really care how many files are in a directory, unless they have names that are annoying to autocomplete.

If that were the case, why would we bother separating out code into multiple directories at all?

The reason we bother with modules and directories is to help organize code and ease discovery. And whether we use ls or a GUI, we all start out the process of discovery with a directory listing.

The top-level directory, where these files are, is often where there's the most flexibility in terms of how to lay out things. All this clutter hides the project organization and makes it difficult to discover what's going on. It was one thing when it was just autotools, but the proliferation of tools in the last decade has brought it over a tipping point, IMHO.

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

#202

Post by vorpalhex »

dfee wrote: post #96
jolux wrote: post #81

Earlier quoted context omitted.

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.

JS is a great language for it's intended purposes but I still can't get onboard the TS train. Adding types post-hoc has never improved a codebase that I've seen but it has caused a lot more bad patterns to show up.

Simplicity is a virtue (at least sometimes).

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

#204

Post by tomc1985 »

rapnie wrote: post #137
tomc1985 wrote: post #111

Earlier quoted context omitted.

Exactly... the problem isn't the proliferation of config files, it's the use of so many tools that require those config files

So are you advising developers to use less tools, or maybe all-in-one toolsets? Presumably tools are used to support tasks that were otherwise more onerous and time-consuming and maybe neglected because of that.

Yes, less tools. Perhaps by making better use of existing tools

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

#205

Post by chmod775 »

epistasis wrote: post #201
chmod775 wrote: post #200

This is a problem mainly for people who use GUIs. When you use a terminal you don't really care how many files are in a directory, unless they have names that are annoying to autocomplete.

If that were the case, why would we bother separating out code into multiple directories at all? The reason we bother with modules and directories is to help organize code and ease discovery. And whether we use ls or a GUI, we all start out the process of discovery with a directory listing. The top-level directory, where these files are, is often where there's the most flexibility in terms of how to lay out things. A…

>If that were the case

It is the case: They don't bother me when I'm using a CLI, but when I use Visual Studio Code for instance, all those files are annoying when I'm looking for something/scrolling past them.

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

#206

Post by jolux »

vorpalhex wrote: post #202
dfee wrote: post #96

Earlier quoted context omitted.

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

JS is a great language for it's intended purposes but I still can't get onboard the TS train. Adding types post-hoc has never improved a codebase that I've seen but it has caused a lot more bad patterns to show up. Simplicity is a virtue (at least sometimes).

> Adding types post-hoc has never improved a codebase that I've seen but it has caused a lot more bad patterns to show up.

I mostly meant that I do all my greenfield JS dev using TypeScript. Out of curiosity, what bad patterns have you seen caused by adding types “post-hoc”?

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

#207

Post by rumanator »

pm215 wrote: post #163
Legogris wrote: post #129

Earlier quoted context omitted.

> The same argument is made for not adhering to the XDG spec for user configuration files I think it's a fundamental difference in that the project repo should be self-contained and "owned", whereas arbitrary software I run really shouldn't be putting files in my home directory. In a software repo, anything inside it belongs to the project.

I think there are similarities -- the project's root is the project's, so why does eg the Travis CI system get to insist on having a config file sat in the project root?

> the project's root is the project's, so why does eg the Travis CI system get to insist on having a config file sat in the project root?

Because it defines the project's CICI pipeline? Aka how the project is built, tested, delivered, and deployed?

I mean, that's a more fundament part of the project than which files should be automatically ignored when committing stuff to git (i.e., .gitignore)

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

#208

Post by rumanator »

addicted wrote: post #151
rapnie wrote: post #137

Earlier quoted context omitted.

So are you advising developers to use less tools, or maybe all-in-one toolsets? Presumably tools are used to support tasks that were otherwise more onerous and time-consuming and maybe neglected because of that.

How about an all in one config file? You have a standard JSON config file “.config.json” that resides in the root folder with a global object, with each key containing the config for each tool. Collisions might be a concern, but you could use the tool’s url as the key so it’s unique. You are already seeing runtimes like Deno and Go do that for importing source code. Couldn’t the same thing apply for this config file…

> How about an all in one config file?

What an awful idea. I don't even know where to start enumerating the problems that this approach creates, and what for? I mean, just think about it. Have you ever had to comb through a config file to add support for something but while you were not sure what option dictated which and what impact this or that option had because documentation is ineffective or awful or even non-existent?

Now multiply that complexity by all the options added by all the tools expected to use a file, compounded by the fact that God knows how many tools also write to that file and may or may not stay in their lane when doing so.

Who in the hell wants to deal with that mess?

And what for? Just because someone wants to adopt a tool but has a problem with having to configure its own config file?

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

#209

Post by rumanator »

vorpalhex wrote: post #202
dfee wrote: post #96

Earlier quoted context omitted.

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

JS is a great language for it's intended purposes but I still can't get onboard the TS train. Adding types post-hoc has never improved a codebase that I've seen but it has caused a lot more bad patterns to show up. Simplicity is a virtue (at least sometimes).

> JS is a great language for it's intended purposes

Which part of JS, as a programming language, do you see as great or even adequate when compared with contemporary programming languages?

> Adding types post-hoc has never improved a codebase that I've seen but it has caused a lot more bad patterns to show up.

That assertion makes no sense. I mean, all TypeScript does is impose arbitrary sanity checks on a programming language which is plagued for not having any. Where do you interpret the addition of sanity checks as a source of problems?

Post reply on HN