mirror of https://github.com/spf13/viper.git
docs: propose deprecating the global Viper instance
Signed-off-by: Mark Sagi-Kazar <mark.sagikazar@gmail.com>
This commit is contained in:
parent
c943b3ef27
commit
99e9188c7c
|
@ -6,6 +6,8 @@ Date: 2021-07-20
|
|||
|
||||
Proposed
|
||||
|
||||
Referenced by [8. Deprecate the global Viper instance](0008-deprecate-the-global-viper-instance.md)
|
||||
|
||||
## Context
|
||||
|
||||
The Viper struct currently acts as a facade for reading, writing and watching configuration for changes.
|
||||
|
|
|
@ -0,0 +1,23 @@
|
|||
# 8. Deprecate the global Viper instance
|
||||
|
||||
Date: 2021-09-23
|
||||
|
||||
## Status
|
||||
|
||||
Proposed
|
||||
|
||||
References [5. Deprecate setters in favor of functional options during initialization](0005-deprecate-setters-in-favor-of-functional-options-during-initialization.md)
|
||||
|
||||
## Context
|
||||
|
||||
With the deprecation of setters in favor of functional options, it becomes almost impossible to get away with instantiating Viper.
|
||||
In addition to that, people should be discouraged from accessing a global Viper instance.
|
||||
|
||||
## Decision
|
||||
|
||||
Deprecate the global Viper instance and the global access functions.
|
||||
|
||||
## Consequences
|
||||
|
||||
People will still be able to create a global instance of their own,
|
||||
but instantiating a custom Viper instance will become the primary solution for using Viper.
|
Loading…
Reference in New Issue