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

Most upvoted comments

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