You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently file encoding is hard-wired into Viper which makes every consumer download the dependencies of all supported formats, even if they only want to use one or two (json, yaml, toml to name the most popular ones). These dependencies even make their way to the final binary.
In Viper 2 we want to lower the number of dependencies. One way of doing that is getting rid of all the encoding libraries from the Viper core, and requiring consumers to manually import the formats they want to use:
package main
import (
"github.com/spf13/viper"
_ "github.com/spf13/viper/encoding/yaml"// Add YAML support to Viper
_ "github.com/spf13/viper/encoding/json"// Add JSON support to Viper
)
// ...
Although moving the encoding libraries to separate modules would be a breaking change, there is no reason against moving the code to separate packages inside the main module in Viper 1 and move them to separate modules to Viper 2 if we decide to break backwards compatibility.
Until there is actually need for people to import those packages manually, they should remain internal: github.com/spf13/viper/internal/encoding/....
The text was updated successfully, but these errors were encountered:
The main pain I feel and the biggest impact on dependency and code size is the remote config though. Remote config is already half-separated from the core and fully splitting it would already get large part of the job done if making everything optional is not achievable short-term.
Currently file encoding is hard-wired into Viper which makes every consumer download the dependencies of all supported formats, even if they only want to use one or two (json, yaml, toml to name the most popular ones). These dependencies even make their way to the final binary.
In Viper 2 we want to lower the number of dependencies. One way of doing that is getting rid of all the encoding libraries from the Viper core, and requiring consumers to manually import the formats they want to use:
Although moving the encoding libraries to separate modules would be a breaking change, there is no reason against moving the code to separate packages inside the main module in Viper 1 and move them to separate modules to Viper 2 if we decide to break backwards compatibility.
Until there is actually need for people to import those packages manually, they should remain internal:
github.com/spf13/viper/internal/encoding/...
.The text was updated successfully, but these errors were encountered: