Enhance Configuration Management about nodegoat HOT 3 CLOSED

I'm still strongly against this over-engineering proposal. I'll reiterate my points from the email thread so there'd be a central log of the arguments:

Karl Düüna (@DeadAlready) wrote:
For configuration management I suggest we use a node module designed for that - makes it more concise and better to comprehend

I disagree. What Chetan has now is a beautifully simple and working solution. Plain JSON works and a simple extend/merge works. There's no need for, again, another dependency that would require a security review, learning and maintenance. That's added complexity. So, no — KISS.

Or unless I'm misunderstanding the point of the example app — to show bad design and security decisions — in which case I'm all for adding useless modules as extra attack vectors. :-)

Karl Düüna (@DeadAlready) wrote:
Configuration - the current configuration system is sufficient until the complexity of this project grows.

Perfect! :-) As more roads to hell are paved with assumptions than otherwise, YAGNI is a great principle to remember. ;-)

Karl Düüna (@DeadAlready) wrote:

• Lacks features that I find very useful when developing - like overwriting configuration properties from command line.

Which settings would those be and for the few that there are, would env vars suit, too?

Karl Düüna (@DeadAlready) wrote:
And secondly the current configuration system requires underscore - which is more than 1300 lines of code and 80+ functions, to use one function and about 10 lines of code - so not exactly in line with your comment as an argument against using some other module designed for configuration management.

It's not at all about line count, it's about complexity, trust, learning and maintenance.

• Almost everyone and their mother is familiar with Underscore/Lodash, and if they aren't, a function called "merge" is fairly self-explanatory.
• A third party unidiomatic config library requires learning for everyone.
• Any new library is bound to bring a new set of problems.
• The increase in complexity introduced does not offset the minor added functionality in this case.
• Any new library is a new vector of attack against all developers and app clients. This is so ignored in a lot of dev communities that it's scary.
• A third party library should be reviewed every time its updated. That's maintenance overhead.
• What is there to configure? Let's learn a thing from the world of human-computer interaction and build software with sensible defaults instead.

There are a lot of cases where the benefits outweigh the problems and risks, but a config library isn't one of those.

from nodegoat.

Its hard to anticipate potential project config complexity at this stage. Moving issue to milestone 3 to review again after getting more idea about actual project needs.

from nodegoat.

Closed for version 1.0.0

from nodegoat.