It is recognized as a bad practice because you're creating a file that is not requested anywhere and waiting to rot.
It falls as the same category as bad comments hinted by Robert C. Martin, Martin Fowler as well as others that have written on clean architecture and code.
Your devs will use their config.dev which is not committed so any time a new config need to be added or removed, there is no strong obligation to change the config.example file because everything will still work the way it is.
If you've ever work on projects with a big team either enterprise or open source. Many of projects using config.example simply doesn't work out of the box because of the config.example being just a piece of lies.
As for 12factors, well the 3rd point, says explicitly:
III. Config
Store config in the environment
I've mentioned the 12factors since the OP already mentioned it in another of his post.
Now without it being the holy grail or anything, it's a set of "best" practices that most if not nearly all recent IT books are derived from when they're talking about production ready code. Not having heard of it in 2018 is something to worry about.
@acostalima
was asking if env was a best practice and you cannot deny him that.
You surely could do another way, a best practice doesn't mean the "one and only".
As you say is depends on your way of deployment. For example, if you're running on cloud providers like AWS, then use of secret manager makes a lot of sense for any secrets config.
Your devs will use their config.dev which is not committed
Um no, don't do that. Use a config that IS committed as the developer environment config, so when you add something to it you automatically set the correct value for all other devs.
Regarding the config.example issue.
It is recognized as a bad practice because you're creating a file that is not requested anywhere and waiting to rot.
It falls as the same category as bad comments hinted by Robert C. Martin, Martin Fowler as well as others that have written on clean architecture and code.
Your devs will use their config.dev which is not committed so any time a new config need to be added or removed, there is no strong obligation to change the config.example file because everything will still work the way it is.
If you've ever work on projects with a big team either enterprise or open source. Many of projects using config.example simply doesn't work out of the box because of the config.example being just a piece of lies.
As for 12factors, well the 3rd point, says explicitly:
I've mentioned the 12factors since the OP already mentioned it in another of his post.
Now without it being the holy grail or anything, it's a set of "best" practices that most if not nearly all recent IT books are derived from when they're talking about production ready code. Not having heard of it in 2018 is something to worry about.
@acostalima was asking if env was a best practice and you cannot deny him that.
You surely could do another way, a best practice doesn't mean the "one and only".
As you say is depends on your way of deployment. For example, if you're running on cloud providers like AWS, then use of secret manager makes a lot of sense for any secrets config.
Um no, don't do that. Use a config that IS committed as the developer environment config, so when you add something to it you automatically set the correct value for all other devs.
Anyway, there is little point in continuing this.
Thanks you both for your insights. 🙂