Feedback: Transformation / upgrades.

[ryantheleach]

This seems like a good utility, but it seems far from being a complete solution.

Is there plans to add migrations / upgrades / in-app mutation/setting of config values?

[japgolly]

Hey Ryan. I used it in multiple serious products and find it a complete solution for my needs. I don't do mutation but you can call .map (and various) on ConfigDef if that's what you mean by transformation. As to migrations and upgrades I don't know what else you're looking for. Could you elaborate?

[ryantheleach]

Maybe I'm misunderstanding the purpose/scope of the library, But from the readme, it seems like it only handles inheritance of configuration values, and debugging them?

Maybe it's my fault for only reading the readme after coming from Reddit.

Re: Transformation/Migration I was referring to Schema changes of the config, and backwards compatibilty concerns.

Being able to read, rewrite, and upgrade them as the application evolves.

[japgolly]

It creates an instance by reading from multiple prioritised sources. You're right that it doesn't have any features to specifically deal with config versioning. Maybe we follow different practices but in my experience, depending on the change I'm introducing I'll either decide to allow un-upgraded config sources or not; in the case that I do I use a default, in the case that I don't I make the new keys mandatory and envs break if I upgrade them without upgrading the config. It would be a different case if I didn't have control over all config sources and/or envs and I wanted to be very ambitious about dual support but I don't. That's not to say one couldn't using this (quite simply one could just specify a version key and use .choose to select a config version depending on its value) but it's not something I've provided privileged API.