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

151–160 of 214 posts

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

#151

Post by addicted »

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.

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 as well?

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

#152

Post by reillyse »

_ZeD_ wrote: post #106
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

this is the solution :) ... I miss rails where everyone knew where everything was supposed to go, a little like how much I love prettier now - no more stupid bike shedding conversations about coding style.

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

#153

Post by eckza »

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…

My god, I love Elm.

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

#154

Post by rumanator »

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.

>So are you advising developers to use less tools, or maybe all-in-one toolsets?

No, you're the only one arriving at that conclusion.

The whole point is that if you're going to adopt tooling then you'll need to configure them all, and that's fine with config files in the project root tree.

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

#155

Post by iainmerrick »

gumby wrote: post #145

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 .

The .editorconfig specifies things like tabs vs spaces and the indent size. Everybody needs to use the same settings to avoid messing up the formatting every time they edit a file. Therefore, .editorconfig gets checked in so that everybody gets the same settings.

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

#156

Post by paulie_a »

thayne wrote: post #10
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.…

I like the idea of a single consolidated config file as long as: 1. It supports real comments (so not json) 2. It supports imports/includes so if it gets unwieldy it can be split up.

Splittig it up so you can also determine the environment. I do this with Django settings the time: base/common, local, testing, production. The latter are very tiny and contain small bits of extra configuration.

Personally I like this approach way more than a bunch of if/else statements in a single file.

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

#157

Post by rndgermandude »

hnzix wrote: post #113
throw_m239339 wrote: post #112

The good old "conventions" vs "configuration" debate. Seems like Javascript looks more and more like Java with all these manifests. Though XML solved the issue of needing multiple config files long ago, with namespaces.

Now we just need to finish moving from REST to pseudo-RPC and we'll have come full circle back to the 90s. Does this mean I can put bevels on my UI buttons again?

*gRPC ;)

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

#158

Post by alephu5 »

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…

That's how I configure my projects using dhall.

I'm working on a web application at the moment with a REST API, database, rabbitMQ, a few python workers, nginx, 2 react projects and a Gatsby project plus some docker composes for testing.

Everything is configured in the root file and then this is imported into smaller dhall files in the subprojects. In the build scripts I generate all the yaml and JSON from these, even the docker-composes and it's very ergonomic.

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

#159

Post by dmurray »

_ZeD_ wrote: post #105
ksenzee wrote: post #20

Earlier quoted context omitted.

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

But some (most) config belongs in version control, and other parts are environment-specific: perhaps a different path to your database in prod vs development, or instructions for your IDE that may not be to the taste of someone else working on the project with the same IDE.

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

#160

Post by GenKali »

alephu5 wrote: post #158
addicted wrote: post #151

Earlier quoted context omitted.

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…

That's how I configure my projects using dhall. I'm working on a web application at the moment with a REST API, database, rabbitMQ, a few python workers, nginx, 2 react projects and a Gatsby project plus some docker composes for testing. Everything is configured in the root file and then this is imported into smaller dhall files in the subprojects. In the build scripts I generate all the yaml and JSON from these, eve…

First I'm hearing of this tool and it seems really nice. Do you perhaps have an open repo that shows how you are using the dhall files? If I can reduce my config files to dhall + justfile I'd be quite happy.
Post reply on HN