Confederate - Tight Conf Loader
Why?
We wanted the init of apps tiny and tight. We wanted it aimed at suits of microservices.
Every app has a name configured in code. That's used for identification in logging, and for specific conf file - when needed. Confederate utilizes that. It also looks for a common conf. They're merged — with top-level keys granularity only. That's it. Because "fancy and elaborate" complex chains of inheritence, variable expansion and merging have avsolutely no place in app-confs at run-time. When you need that, you solve it in a conf-build stage. You want to catch problems at build time, not at deploy-time on server, with it's invariably differing setup compared to your dev-situation. Also, we all love yaml, etc — but again, that convenience saves no time in a deployed conf situation. For that: again, add a build-stage for the confs! Don't be lazy in the wrong places!
Details?
It's picky. Pass my-app --conf the-conf-dir
, my-app --conf=the-conf-dir
or CONF=the-conf-dir my-app
. A specific conf-file-path be passed instead of dir.
With the dir, it looks for "the-conf-dir/common-defaults.conf.json" and "the-conf-dir/the-app-name.conf.json" and merges them at top-level keys granularity only — yes, that's a feature — with the app-specific properties naturally taking precedence.
It's written in TypeScript for buildtime insurances.
In progress...
More details to come — and changes. The goal is to reduce it to the least possible amount of code. Don't use this until v1.0.0, you've been warned.