How to avoid Hugo Modules?

support
1

I’ve been on old versions of Hugo for a while, and my standard workflow has been hugo new site mywebsite.com then download code as ZIP from a theme’s Github repo, extract and place in /mywebsite.com/themes, then copy the exampleSite folder up a level to see what it’s supposed to look like.

However, recently, I’ve noticed several themes (for example, Hugo Gallery) that use Hugo modules, so the example site fails to build by default. Is this some new behaviour from new Hugo versions causing it to fail? How do I not use Hugo modules? I want to download the code as a ZIP, put it in /mywebsite.com/themes and have it work; rarely, for some friends websites, I use git submodules, and I don’t want to have to install GoLang as a dependency just to use Hugo, nor do I want to use Go’s package management. Dependencies and sub-dependencies get in the way when I’m trying to teach less skilled friends how to build a simple website, as well as in the way of my own web hobby, so I already never use any themes that need NPM or SASS, and I’m allergic to package managers.

2

I tried deleting go.mod, and could potentially waste hours poring through a typical module-ised theme deleting all references to Hugo modules and manually resolving dependencies.

Is there a quicker way to do this, one config line or file I can delete to make a module-ised theme work like a normal theme? I’m also worried that more and more themes will become module-ised, e.g. even good old Ananke seems to have gone that way and (when I last tried on Friday) no longer builds the example site because it can’t resolve Go packages.

Git submodules are fine as an optional extra outside of Hugo, for mass deployments or frequent updates, and they didn’t break Hugo functionality… Hugo modules seem to be a whole different story :cry:

3

There’s no automatic way to convert a Hugo module to a static ZIP variant in the themes folder.

In fact a Hugo module is still just a theme, no need to remove the go.mod or anything.

As you can see in your Gallery example it can be also installed as git submodule. And a git submodule is more or less just a tracked way of using git clone.

  • Module (after go installation and hugo mod init)

    [module]
  [[module.imports]]
    path = "github.com/nicokaiser/hugo-theme-gallery/v4"

  • use as a submodule

    git submodule add --depth=1 https://github.com/nicokaiser/hugo-theme-gallery.git themes/gallery

    theme = 'gallery'

  • use as git clone

    git clone --depth=1 https://github.com/nicokaiser/hugo-theme-gallery.git themes/gallery

    theme = 'gallery'

  • most repos allow downloading a zip and some provide a release zip, just download

Options:

  • so manually recursive replacing the import with theme + downloading to respective themes/folder should do the trick (versioning?).

  • another way would be to create a site importing all modules and then use mod vendor to physically place the module inside the site. and then pack that thing no Go or git needed after. see in related posts of your one. Go Modules vs git submodule? - #6

off topic, don’t wan’t to start a discussion about
looks like you have a very special look on these “modularization” topics … In fact Hugo’s Modules don’t import Go modules. Theme Modules are just theme components. It’s a quite save way to modularize a theme.

your argumentation remembers me of the ancient days where we discussed about .so and .dll, ruby gems or git submodules, …

2 Likes