The name... is
ThePrimeagrug 🪨 🧠
https://twitter.com/GrugBrainedDev
https://grugbrain.dev
https://twitter.com/michael_webdev/status/1672977491462332418
https://twitter.com/WarrenInTheBuff/status/1672839156647575552
THIS ISnot🤢FINE.
...
jsit's all so tiresome... 20230625_132253.png
I see no problem with all those config files. Each is for a specific piece of config, to handle a specific function within the codebase. I see it as no different than having a bunch of .h files that have shortcut macros in them. The only problem I see is the lack of a README to let new developers know what they're for.
From the list of files, I can tell
1. they're writing code in TypeScript to be run on a NodeJS server and/or in browsers
2. using docker containers
3. storing their source code in GitLab
4. using environment variables to run their code differently on their dev machine than on the cloud (most likely just different config variables)
5. making their code adhere to coding layout and standards using ESLint and Prettier
6. making their IDEs all behave the same so they see the same code the same way
7. writing unit tests using Jest
8. deploying their app by webpacking it
9. writing web code that is backwards-compatible via shims and various techniques without having to hand-code it all themselves
Every one of those files all serve a purpose. And no question they are a far better way of storing config info than in the Windows registry etc.
It just has gotten way more complex than anyone could have predicted 10 years ago. Getting similar to how a typical Java project configuration feels at fiest skim.
Luckily an NPM package can still just be a simple `.js` file plus a minimal `package.json` that was built with `npm init`. Hope that is never not true! 🙏