Combine the two. Build some common bits directly into the default layouts, archetypes, etc., and use a theme that only provides the layout, colors, typography, etc.
I am curious about the benefits and tradeoffs of the options listed above. There is most likely no right answer, but I would love to learn from those that have done this kind of thing before. Thanks!
those who are not knowledgeable enough to build their own layouts; or
reusing across different sites.
If you don’t intend to do number two, just stick to the base Hugo layouts.
Personally, I use a theme because I like to declutter my Hugo project. So, I only keep the config, content, data, and static folders in the base and the rest (archetypes, assets, layouts, i18n) in a theme in the themes folder.
Thanks, Arif. I do think I am starting to lean toward the approach you mentioned you prefer. Another benefit of defining the look & feel in a theme means one can offer different themes but have all the logic, content, shortcodes, and CMS integration bits in the base of Hugo.
Because ‘theme’ means a specific thing in Hugo I prefer to use the term ‘skin’ to describe a different look & feel and ‘theme’ to describe the ‘Hugo logic’ (layouts/* etc) that gets used with theme = xxxx in config.toml.
But that’s just a personal preference for attempting to keep clear what I am referring to.
Another option is to not use the theme = line and just have what I’d call a ‘skin’ Hugo module, and a layouts-logic module.
Themes as theme = is more relevant when not using Hugo modules, since it allows the use of git submodules or an archive (zip, tar.gz, etc) of the theme.
Some users on the forum like to decompose into many different modules (I’m sure @davidsneighbour would love to opine on that) and use them as building blocks for the site.
I find the ‘bookkeeping’ associated with that more trouble than it’s worth, but it is an option.
I am evolving due to the complexities and length of building the site with (too) many modules currently working on a module that “has them all” in one single module.