viper: with 1.13.0, breaking change has been introduced on yaml
Preflight Checklist
- I have searched the issue tracker for an issue that matches the one I want to file, without success.
- I am not looking for support or already pursued the available support channels without success.
- I have checked the troubleshooting guide for my problem, without success.
Viper Version
1.13.0
Go Version
1.19
Config Source
Defaults
Format
YAML
Repl.it link
No response
Code reproducing the issue
package main
import (
"fmt"
"github.com/spf13/viper"
)
func main() {
v := viper.New()
v.AddConfigPath(".")
v.SetConfigName("conf")
if err := v.ReadInConfig(); err != nil {
panic(err)
}
var seq []seq
if err := v.Unmarshal(&seq); err != nil {
panic(err)
}
fmt.Println(seq)
}
type value struct {
Bool bool `mapstructure:"bool"`
}
type Map map[string]value
type seq struct {
List []Conf `mapstructure:"list"`
}
type Conf struct {
Config Map `mapstructure:"conf"`
}
with config :
list:
- conf:
FR:
Bool: false
- conf:
FR:
Bool: true
EN:
Bool: false
Expected Behavior
with 1.12.0, seq equals [{[{map[FR:{false}]} {map[EN:{false} FR:{true}]}]}]
with 1.13.0, seq equals [{[{map[fr:{false}]} {map[en:{false} fr:{true}]}]}]
Actual Behavior
expected we have the same case FR not fr for the key map
Steps To Reproduce
No response
Additional Information
No response
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 17
@ldez @jerome-laforge due to popular demand, I’m going to allow reverting back to the previous behavior using a go tag.
#1576
Thank you for trying to help me to find solution ❤️
Well, case sensitivity has been long debated and requested as a feature, but ultimately it doesn’t fit the primary goals of the library. Most of it was already case sensitive before this release. The only reason it worked for you because you used an array. In every other scenario, it would be converted to lower case even before the last release.
See #1014 for more details.
Yep, the previous behavior was the result of a bug which is now fixed.
Thanks for reporting @jerome-laforge ! Give me some time to debug what may have caused this, but I have a gut feeling it’s an encoding library issue.