poll: Allow partial outputs configuration

[bep]

In Hugo, the default outputs configuration looks like this:

[outputs]
  page = ["HTML"] 
  home = ["HTML", "RSS"] 
  section = ["HTML", "RSS"] 
  taxonomy = ["HTML", "RSS"] 
  taxonomyTerm = ["HTML", "RSS"] 

This is what you get when doing nothing.

The current behaviour says that if you provide your own outputs configuration, it must be complete.

We do, however, add HTML as a fallback for a missing config entry. But, currently, if you want to add JSON to the home page (for a search index), this:

[outputs]
  home = ["HTML", "RSS", "JSON"] 

Will result in missing RSS for the other list types.

See this for background: https://discourse.gohugo.io/t/need-to-redefine-the-whole-outputs-map-when-needing-to-set-just-one-kind/10953/19

The current behaviour is analogous to setting the related config and the sitemap config and the permalinks config. You have to provide the complete definition. The thought is, that there is nothing particularly special about the RSS output format, and if a user wants his/hers own config, even the absence of entries has a meaning.

This issue is a little poll to gather some input from Hugo users. We could change this behaviour if the above makes only sense to @bep who implemented it.

[RickCogley]

My vote is for the current, because, once you know there is a consistent rule, it's easy to remember and plan for.

"If you provide related, sitemap, permalinks or output configs, you must specify them completely."

That being said, it would be good if there is a clear documentation page on this rule, so people can be made aware of its consistent implementation. That is, if there isn't one already (sorry, haven't checked...).

[kaushalmodi]

@RickCogley

First It's a two part problem:

1. It is not consistent. The actual rule is more like:

"If you provide related, sitemap, permalinks or output configs, you must specify them completely, but if you provide some other configs, you can override selected keys."

2. Even if all the configs were consistent with outputs behavior, it is not expandable to all the future configs, like an upcoming frontmatter config (this config is going to be awesome!). It will be impractical to completely define whole configs when trying to modify one or few keys.

So I am proposing this change in outputs behavior so that the set of "need to re-specify completely" configs reduces.

But of course, democracy will win, and I will respect that.

I am with you on the point of documentation :)

[bep]

because, once you know there is a consistent rule, it's easy to remember and plan for.

That is not the currently the case. Take the example of https://gohugo.io/templates/output-formats#media-types -- it would not make sense to make the user define all the media types just to add or modify one. The same with outputFormats.

I think the closest thing to a rule here is this:

• outputFormats, mediaTypes, related, outputs, permalinks(and maybe others) translates into a map in the config.
• For maps with entries of the same type (mediaTypes), Hugo allows redefinition of just one or more entries.
• For maps with entries of different types (related), you must provide the full configuration. The different entries only make sense in relation to the others.

Note that outputs (which is this discussion) does not follow the above rule.

I notice I have put this in the wrong repo, but that does not matter. Thanks to @kaushalmodi for being persistent about this -- I will create another issue in the hugo repo and fix this there. If you see any other similar config sections in Hugo that does not follow the rule above, create a bug.