Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite the encoding layer as a library #888

Open
sagikazarmark opened this issue Apr 9, 2020 · 1 comment
Open

Rewrite the encoding layer as a library #888

sagikazarmark opened this issue Apr 9, 2020 · 1 comment
Assignees
Milestone

Comments

@sagikazarmark
Copy link
Collaborator

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/....

@andig
Copy link
Contributor

andig commented Apr 22, 2020

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.

@sagikazarmark sagikazarmark added this to the v2 milestone Dec 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants