Switch from mitchellh/mapstructure to go-viper/mapstructure

[jkroepke]

Reference: https://github.com/mitchellh/mapstructure/issues/349#issuecomment-1860372162

mitchellh stops the maintenance for mapstructure and other projects.

The mapstructure project is already forked by viper project, since they have a strong dependency against it.

https://github.com/go-viper/mapstructure

[jxsl13]

that's a good one.

[knadh]

hm, I'm very skeptical of anything related to Viper. koanf was born out of the frustration with Viper. See: https://github.com/spf13/viper/pull/635

[jkroepke]

I can understand you here and I also has some reasons why I'm using koanf instead viper.

But what is the alternative? Stay on the unmaintained version which has some unreleased bug fixes? Fork and own mapstructure? Deprecate koanf.Unmarshal?

At least for the bug above, I can use a replace directive on my go.mod file, but the v2 is using an other package path.

I would appreciate a long time solution.

[knadh]

Yep, can't depend on a frozen repo. We can wait for a bit to see who else forks (and what other roadmaps emerge). If nothing else comes up, then we can switch this fork.

[jkroepke]

Seems like the go-viper fork is the designed fork for mapstructure. The current owner is fine with that the go-viper fork does som advertisement on opened PRs.

[jkroepke]

@knadh would it be possible to perform a release?

[knadh]

Ah, missed that. Just released v2.0.2

[james-d-elliott]

This may deserve some additional consideration since it's an unintentional breaking change. I don't have a firm opinion either way, as I feel the migration path is minimal for a majority of repositories. But it probably at least warrants a note.

The specific breaking change is that the koanf.UnmarshalConf struct's DecoderConfig field has changed.

[anuraaga]

Ran into this as well as we do automatic go updates for minor versions and correct semver should never result in a breaking build. But it's probably too late to fix now since people will have already made the fixes vs the breaking change.

For a potential v3, I'd recommend making sure the public API of this library does not expose any APIs from other libraries. In the case of DecoderConfig, it would mean having a similar struct in this repo that is converted for use with mapstructure. Somewhat annoying code but allows owning destiny in terms of compatibility.

[pavelpatrin]

Folks it is not a minor update. You have broken all the code which uses DecoderConfig from the old path and lead compile errors.

It is not good.

[knadh]

Ouch. Never realised that the fork had a breaking change. Tests all passed. Will push a go.mod retraction like @rhnvrm suggested.

[james-d-elliott]

For reference the breaking portion of the change is the module name coupled with the direct reliance on this struct, since the structs module path is different people will have to update that locally to update. Just ensuring we avoid a misconception about the issue. Anuraaga also makes a valid point about the users who've already updated will have to git revert as well.

[james-d-elliott]

Sorry, mistagged the above reply. Was meant to be for @knadh, apologies to the other user.

[knadh]

This was a very unfortunate oversight ;(

https://github.com/knadh/koanf/pull/270 adds a "retract" to 2.0.2 and v2.1.0 has been added as a new tag. Pipelines shouldn't silently/automatically break now.