[foepys]

As much as I am a fan of monoliths, too many configuration parameters will land you in a world of hurt.

You may start with 20 options but people will demand more and more options if you don't stop them very early. Those options will have side effects that other options are supposed to fix and those will also have side effects and in the end you have 1000 options, all doing various things nobody knows. The worst part was: since every option was global, people used options for things they weren't supposed to be used for across multiple modules.

I worked at a company with over 15,000 options in their on-prem monolith. Nobody can know about all of them and each consultant demanded more and more customer-specific options.

It was a nightmare and we tried to get the mess sorted with a plugin system where each plugin had their own options that couldn't pollute the global configuration. But it was very hard, very painful, and in the end we could only eliminate a few thousand global options.

[jsrcout]

I think the developers of the system I work on used your product:-). Although I don't think it has plugins. They said that in the early days they brought in a vendor engineer for a week to configure it. Currently the main config file is over 3K lines and some variants are close to 10K.

[pshirshov]

This is not correct.

Not all the options are equal.

It's possible to soundly define, verify and instantiate big modular contexts.

https://github.com/7mind/izumi/

[sokoloff]

Things that are possible are frequently not the default condition.

[pshirshov]

What forces you to stick to the suboptimal "defaults"?