Allow config.toml to extend another config file

feature
1

I recently realized it was possible to merge several config files using the --config flag of the Hugo command. with hugo serve --config a.toml, b.toml thanks to this commit.

The most common use case for this is to define several layers of configuration depending on your environement.
Users will have a base file stating all the shared config properties and then use another config files with the few properties unique to an environement to be merged on top of it like so

#config.base.toml
DefaultContentLanguage = "en"
MetaDataFormat = "yaml"
title = « My Website » 
theme = "onefinetheme"
[...]

#config.base.toml
[params]
  env = "local"
  contactFormApi = "https://api.mail.loc"

# config.prod.toml
[params]
  env = "production"
  contactFormApi = "https://api.mail.com"
  disqusShortname = "commentswelcome"

$ hugo --config base.config.toml,prod.config.toml

This is the proper way to manage several environments config files sharing many common properties I think.
But as this is a major feature and for a very common use case, I don’t think this capability should be left isolated to a mere cli command flag but rather made into a dedicated configuration feature which does not rely on cli.
This would allow a proper documentation of the feature and advertising of the proper way of sharing common configuration on several environements.

In this sense why not add a configuration property called something like “extends” which will let Hugo know a configuration file uses (and overwrites) the properties of another one like so:

# config.local.toml
expand = "config.base.toml"
[params]
  env = "local"
  contactFormApi = "https://api.mail.loc"

# config.production.toml
expand = "config.base.toml"
[params]
  env = "production"
  contactFormApi = "https://api.mail.com"
  disqusShortname = "commentswelcome"

Cheers

2

Isn’t your suggestion tied to the CLI?

3

Well like any hugo build.
But the default config could point to another file to extend/inherit and save us a config flag listing multiple files.

I would find this way more intuitive, simpler and easier to document and promote.

4

You are still talking about advanced usage.

And any prod vs test will have to do

hugo --config=config-test.toml

hugo --config=config-prod.toml

Etc.

You can wrap the multi-file variant in a shell script (bat file on Windows) and it would not be much harder.

I agree about your suggestion being slightly cleaner, but I’m not totally sure it is worth the extra work.

5

And I agree it is not worth the extra work just yet.

After the config merging thing gets documented a lot of users will use this to build on their different environnements and it will probably content everyone. It just reads more like a hack whereas Hugo could have a neatly designed and documented system for managing several environment config.