A tweak to the architecture of Hugo sites to facilitate fine-grained control over reuse of components

My idea is to split the root directory of a Hugo site into “specific” and “generic” directories, then most of the existing directories can be duplicated in both of these … and then the generic folder subtree can be treated more easily as a git submodule in a dozen different Hugo sites that all reuse, e.g., that same config settting (e.g, default editor), that same custom shortcode, that same post archetype, that same static file, that same scss asset that overrides the third-party theme, etc … while that partial that has to be specific to each site† still goes into the specific/layouts folder (and thus is unique to the parent git repository)

Maybe Hugo modules address this reusability idea, I don’t know, I stopped using modules because for me it’s just easier to use a git submodule, and then when a third-party theme is present as a directory in my site, it’s faster for me to experiment with copying bits of their layouts and such up into my own personal layouts override directory … and then it also doesn’t matter whether or not the default GitLab hugo image supports modules or not either.

† I have a bit that is unique to each site because the internal Google Analytics template does not put Google Analytics at the very top of the page like I want it, so I can’t use the config option for Google Analytics

Could you please read the docs about Hugo Modules and compare to your vision?


You can use module mounts with Git submodules.

You can use module mounts with Git submodules.

I will look into this again, even though I think I will have to use a nonstandard Hugo image on GitLab Pages.

On a related tangent, I guess there is no way to take very specific subsets of the config files and place them into arbitrarily-named files of specific, reusable groupings of various config bits (whether the bits are standard to Hugo†, or params standard to a given reused theme)? And this is just a limitation of the Hugo dependency Viper? Is there any chance that in the long term Hugo might have its own native config system that is more flexible?

† For instance, on every site I would disable the generator injection bit, but I’ve got to manually remember to include that bit in my config/_default/ config.toml file (unless I’ve overlooked a better way than relying on my memory).

We have our own native config system which is pretty flexible (too flexible, some may argue).

We have our own native config system

Oh, I thought it was based on Viper, my mistake