So it’s hell for every tool to have a somewhat easy and similar way to customize it to your exact needs? Hard to imagine that working better imo. If there’s a problem here, it’s that you’re overusing tools.
If you think this is hell, you should try using terraform. Some of the most common basic cloud things will mean hundreds of weird, largely illegible files
If all configs could use the same format and be in the same place, that would be nice. Although I think eventually you’d want to split out that config file into multiple places, because having a config thousands of lines long would suck.
If the picture in the OP is the only alternative, I wouldn’t mind, you can easily collapse json/yaml and only focus on the section you need. Maybe split into files based on functionality.
Aren’t these configs in the OP already split by functionality though? If each of these of config files were only going to be a few lines long, having it all in one file would be great.
Well, for example, there’s no reason eslintrc and eslintignore need to be separate files in any scenario, i would group them and prettier into “formatting”. But, yes I agree, one big file is preferred in most scenarios.
I wish something like .config would be a thing for storing configuration files in repositories. Instead we have a .vscode, .github, .gitlab, .idea, .vs, etc
I know XML is very last century but if they could coexist in one file, a file that treats each config section as an object, so we can create a Project Object Model, call it pom for simplicity, and then if you are old store it in xml and the you could have only one file and call it pom.xml and then maybe one day someone can make this very useful file a bit more modern and turn it into json or yaml but for now a single pom.xml could save us from that config hell others speak of
/s
So it’s hell for every tool to have a somewhat easy and similar way to customize it to your exact needs? Hard to imagine that working better imo. If there’s a problem here, it’s that you’re overusing tools.
If you think this is hell, you should try using terraform. Some of the most common basic cloud things will mean hundreds of weird, largely illegible files
If they could all coesxist in one file, preferably json or yaml, it would be better.
If all configs could use the same format and be in the same place, that would be nice. Although I think eventually you’d want to split out that config file into multiple places, because having a config thousands of lines long would suck.
If the picture in the OP is the only alternative, I wouldn’t mind, you can easily collapse json/yaml and only focus on the section you need. Maybe split into files based on functionality.
Aren’t these configs in the OP already split by functionality though? If each of these of config files were only going to be a few lines long, having it all in one file would be great.
Well, for example, there’s no reason eslintrc and eslintignore need to be separate files in any scenario, i would group them and prettier into “formatting”. But, yes I agree, one big file is preferred in most scenarios.
or maybe most of them in a folder? and one file that defines their locations for environment variables
Kind of what .env files are meant for. Not enough tools use them.
I wish something like
.configwould be a thing for storing configuration files in repositories. Instead we have a.vscode,.github,.gitlab,.idea,.vs, etcYeah, code editors really missed the memo that the XDG tried sending out, that (… mostly) works so well on Desktop Linux
I agree it would be nice to have that as an option
You could probably do this pretty easily with a custom pre-build step.
I’m not confident a single 2000 line config file would be better, though. Sounds an awful lot like Makefile hell.
I know XML is very last century but if they could coexist in one file, a file that treats each config section as an object, so we can create a Project Object Model, call it pom for simplicity, and then if you are old store it in xml and the you could have only one file and call it pom.xml and then maybe one day someone can make this very useful file a bit more modern and turn it into json or yaml but for now a single pom.xml could save us from that config hell others speak of /s