Refactor config loading process by turning config into a PORO instead of hash #299
Conversation
|
@EugenMayer I tried to focus solely on refactoring the configuration without touching too much into other stuff... and I also tried to not change the interface of hopefully this amount of changes are acceptable.. 😁 |
|
Great stuff, will have a look at it while i am traveling today. Thank you so much for so much work! |
|
Did some changes, will commit those in about 1 hour, there is quite a change though. Really nice work there and thank you for the test, great tooling and nice ruby skills over there! |
…g to implement them the same way, GlobalConfig did not include its loader yet. Share config implementations properly, use a config locator to actually be able to change / modify paths during scaffolding and other thinsg. Use the config_locator as a path locator only, not a factory ( for half of th configs ) introduce config_serializer to have a specific service to load, expand serialize and deserialize configs, to share implementations but also to be able to change / introduce other ones Ensure we actually run under ruby 2.0 - no usage of heredoc squiggle allowed
|
@ignatiusreza just see the commit messages, hopefully i did not cross your idea, i really like what you did there. Thanks |
|
@EugenMayer nice ones! agreed that it looks better with locator & serializers being separated, and with configurable global config path, we can avoid stubbing in test 👍 |
|
Great contribution, thank you! |
|
Amazing contribution! Great job! |
|
Awesomesauce! |
which would allow us to put more responsibility into the config itself, and turn it into a more reliable source of truth for deciding dependencies..
fix #288 & a prerequisite for #265