different behavior on the same config file but with different format

[ghost]

What version of Hugo are you using (hugo version)?

$ hugo version
hugo v0.82.0-9D960784+extended linux/amd64 BuildDate=2021-03-21T17:28:04Z VendorInfo=gohugoio

Does this issue reproduce with the latest release?

Yes

How to reproduce

1. Create new empty site

2. Create a new yaml config with this content:
   opengraph:
   twitter:

   defaultImage:
   opengraph:

3. launch hugo server - all is ok

4. Create a toml config with the same content but in toml format:
   [opengraph]
   [twitter]

   [defaultImage]
   [opengraph]

5. launching hugo server rise this error:
   Error: "/home/xxxxx/hugo_extended_0.82.0/try/config.toml:6:1": unmarshal failed: Near line 6 (last key parsed ''): Key 'opengraph' has already been defined.

[jmooring]

Hugo is doing the right thing when it raises an error while unmarshaling this TOML data. The TOML spec does not allow duplicate keys.

Hugo should (theoretically) raise an error while unmarshaling this YAML data, because the YAML spec does not allow duplicate keys either. I think we are currently calling Unmarshal instead of UnmarshalStrict.

UnmarshalStrict is like Unmarshal except that any fields that are found in the data that do not have corresponding struct members, or mapping keys that are duplicates, will result in an error.

Currently, with identical YAML keys, the later declaration overrides the earlier declaration. I have no idea if anyone relies on this behavior. There's a chance that switching to UnmarshalStrict would break things, but I suspect this is a low probability.

[bep]

I think I stumbled over this issue when I tried to upgrade to v3 of the Yaml library (which I think is strict with no option to turn it off) -- and I suspect that this was the reason I put that on ice. And I think we need to do it as part of that upgrade ... This is a think we really should do, but it will create a lot of noise/questions both here and on the forum.

[jmooring]

v3 unmarshal docs state:

Conflicting names result in a runtime error.

And there is not an "unstrict" option. So at some point there's going to be some pain.

[moorereason]

The only way to ease that transition is to unmarshal twice: once in normal mode and a second in strict mode to log warnings.

We can control this in yaml/v3 with Decoder.KnownFields(bool), which matches the yaml/v2 Decoder.SetStrict(bool).

[bep]

The only way to ease that transition is to unmarshal twice: once in normal mode and a second in strict mode to log warnings.

Or the other way around:

1. First in strict mode: If all goes well, all is well.
2. If we get that specific error, we log a deprecation warning, then we retry the YAML unmarshal in "non strict" mode.

[jmooring]

Revisit this once #8822 is complete.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.