If you really need to process the configuration in multiple places throughout the app, then you could put that processing code in a service class and put the debug statements there.
Thats essentially what config.js does, why split up configuration in multiple places?
With scripting languages theres no reason to use json for configurtion unless the config is shared between programs. The main reason config files exist is so you can edit the program without recompiling, i feel like people forgot that and kept blindly using json when js or ts is better. My config file is just like 20 lines but putting the extremely simple conditional logic of if its debug if its client if its server there reduces program complexity by a couple hundred sloc.
>The main reason config files exist is so you can edit the program without recompiling
This isn't generally the reason. The main reason config files exist is so you can run the program in in a different state easily. State differs across environments, code should not. This is why you have a config file for prod and test and dev, but you shouldn't have different code for prod and test and dev. You still have to rebuild the app for those environments. See: https://12factor.net/config.
>This isn't generally the reason. The main reason config files exist is so you can run the program in in a different state easily
My ide lets me f12 to my config.js file and i can use editor hotkeys like comment toggle so by this metric my method is superior.
>You still have to rebuild the app for those environments.
As i said above you dont have to rebuild for python and javascript since they can load the config file on the fly. I use xml or json for compiled languages because beign able to change the program without recompiling is of critical importance.
>you shouldn't have different code for prod and test and dev.
You dont have different file for test/dev/prod, you have 1 config file that has a few inline if statments based off of runtime args. For me 1 file is less confusing than 2 or 3.
Well, yes, admittedly it's true that scripting languages do have this unique advantage where you can basically hardcode the configuration in the program code itself and still have it be flexible enough to be called a configuration file. In a situation like that, I agree, it might not make sense to break into two files what can just be done in one.
