`hugo mod init ..` fails to create go.mod if hugo detects an error prematurely in site config.toml

I am converting a bunch of my websites to use Hugo Modules based theme and component fetching instead of using git submodules.

During this conversion, I believe I have come across a bug.

My config.toml of few sites use an output format defined in a separate git repo aka module.

So when I switched to using Hugo Modules, I simply removed the theme variable, themes/ directory and add module imports to my theme-turned-module.

Note that my site is already building using the old themes/ approach and I am just converting to Hugo Modules approach.

So I would need to create a new go.mod using hugo mod init something.something. The problem is that because my config.toml references output formats which will be fetched from the modules, Hugo doesn’t find the definition of those formats yet, and quits with this error without generating go.mod.

WARN 2022/01/20 14:31:36 module "github.com/kaushalmodi/hugo-atom-feed" not found; either add it as a Hugo Module or store it in "/home/kmodi/hugo/hugo_mwe/themes".: module does not exist
Error: from config: failed to resolve output format "ATOM" from site config

One can easily reproduce this error by adding this to their site config, deleting their existing go.mod, go.sum and then running hugo mod init something.something:

    path = "github.com/kaushalmodi/hugo-atom-feed"

  home = ["HTML", "RSS", "ATOM"] # default = ["HTML", "RSS"]

Alternatively, you can clone my minimal reproducible example repo:

git clone https://gitlab.com/hugo-mwe/hugo-mwe
cd hugo-mwe
git checkout mod-init-fail
hugo mod init something.something

You should see a similar error like above and no go.mod will be created.

Workaround: Comment out the output lines from config.toml, run the hugo mod init .. command and then uncomment those output lines.

It took me some unreasonable amount to time to figure out what the problem was. I hope this is categorized as a bug and fixed.

Suggestion: Skip the checking of site config.toml correctness when user is running hugo mod init ...

This was an issue for other users (including me) as well.
Please have a look at this issue comment at GitHub.

Thanks, so it’s not just hugo mod init .. that’s affected. By reading that thread, hugo mod get .. is also affected.

@bep Should all hugo mod .. commands skip checking the functional validity of the site config, except that of the [module] table (hugo mod init .. doesn’t need to check even that) ?

From the inital post:

It took me some unreasonable amount to time to figure out what the problem was. I hope this is categorized as a bug and fixed.

I realize that this problem persists and is not only affecting me, but other hugo users as well, i.e. when using themes that bring in custom output formats. Therefore, as a friendly reminder and ping:

  • Is there consensus that this can be considered as bug?
  • Is/can this issue be tracked on hugo’s github repo?
  • Any plans to address this issue eventually?