Hugo 0.123: module is not imported anymore

I embedded a documentation (which actually is its own Hugo website in itself) inside a website using a module:


[module]
  [[module.imports]]
    disable = false
    ignoreConfig = true
    ignoreImports = true
    path = "github.com/aurelienpierreeng/ansel-doc"

    [[module.imports.mounts]]
      source = 'content/'
      target = 'content/doc/'
      lang= "en"

    [[module.imports.mounts]]
      source = 'content/'
      target = 'content/doc/'
      lang= "fr"

Note: The primary language is EN, and not everything is translated into FR yes.

Up to Hugo 0.122, when building the website, the module gets updated and the documentation gets rendered properly in /en/doc and /fr/doc:

Hugo 0.111.3 installed from Fedora repo:

hugo: downloading modules …
hugo: collected modules in 106781 ms
Start building sites … 
hugo v0.111.3+extended linux/amd64 BuildDate=2023-07-26T00:00:00+00:00 VendorInfo=Fedora:0.111.3-4.fc39

                   | EN  | FR   
-------------------+-----+------
  Pages            | 506 | 296  
  Paginator pages  |   0 |   0  
  Non-page files   | 417 | 237  
  Static files     |  59 |  59  
  Processed images | 188 | 174  
  Aliases          |   2 |   0  
  Sitemaps         |   2 |   1  
  Cleaned          |   0 |   0  

Total in 134429 ms

Hugo 122.0 Go package downloaded straight from Github (something wrong seems to happen with images, we lost 176 of them in EN ?):

Start building sites … 
hugo v0.122.0-b9a03bd59d5f71a529acb3e33f995e0ef332b3aa+extended linux/amd64 BuildDate=2024-01-26T15:54:24Z VendorInfo=gohugoio

                   | EN  | FR   
-------------------+-----+------
  Pages            | 288 |  39  
  Paginator pages  |   0 |   0  
  Non-page files   | 217 |  31  
  Static files     | 147 | 147  
  Processed images |  19 |  19  
  Aliases          |   2 |   0  
  Sitemaps         |   2 |   1  
  Cleaned          |   0 |   0  

Total in 1143 ms

Starting at Hugo 0.123, the module is not loaded at all and the documentation (from the module) is not rendered:

Start building sites … 
hugo v0.123.8-5fed9c591b694f314e5939548e11cc3dcb79a79c+extended linux/amd64 BuildDate=2024-03-07T13:14:42Z VendorInfo=gohugoio

                   | EN  | FR   
-------------------+-----+------
  Pages            |  44 |  40  
  Paginator pages  |   0 |   0  
  Non-page files   |  30 |  30  
  Static files     | 147 | 147  
  Processed images |  19 |   0  
  Aliases          |   1 |   0  
  Cleaned          |   0 |   0  

Total in 264 ms

We are missing 462 pages in the EN version and the 2 sitemaps. What could be the issue ?

Here’s a test site using your module as shown above.

git clone --single-branch -b hugo-forum-topic-48951 https://github.com/jmooring/hugo-testing hugo-forum-topic-48951
cd hugo-forum-topic-48951
hugo server

Then visit http://localhost:1313/en/doc/

When I build with v0.124.1…

hugo v0.124.1-db083b05f16c945fec04f745f0ca8640560cf1ec+extended linux/amd64 BuildDate=2024-03-20T11:40:10Z VendorInfo=gohugoio


                   | EN  | FR   
-------------------+-----+------
  Pages            | 256 | 251  
  Paginator pages  |   0 |   0  
  Non-page files   | 187 | 187  
  Static files     |  96 |  96  
  Processed images |   0 |   0  
  Aliases          |   2 |   1  
  Cleaned          |   0 |   0  

As a gut check on the content count…

hugo mod vendor
find _vendor/github.com/aurelienpierreeng/ansel-doc/content -type f -name "*.md" | wc -l

206

Thanks.

I have a weird issue then. Your exact example, using Hugo 0.124.1 yields:

go: go.mod requires go >= 1.22.1 (running go 1.21.7; GOTOOLCHAIN=local)
...blahblah
Error: command error: failed to load modules: failed to download modules: failed to execute 'go [mod download -modcacherw]': failed to execute binary "go" with args [mod download -modcacherw]: go: go.mod requires go >= 1.22.1 (running go 1.21.7; GOTOOLCHAIN=local)

While runing Hugo 0.124.1 after doing mod clean --all on my project:

hugo: downloading modules …
hugo: collected modules in 70337 ms
hugo v0.124.1-db083b05f16c945fec04f745f0ca8640560cf1ec+extended linux/amd64 BuildDate=2024-03-20T11:40:10Z VendorInfo=gohugoio

                   | EN  | FR  
-------------------+-----+-----
  Pages            |  44 | 40  
  Paginator pages  |   0 |  0  
  Non-page files   |  30 | 30  
  Static files     |  59 | 59  
  Processed images | 188 | 14  
  Aliases          |   1 |  0  
  Cleaned          |   0 |  0  

Built in 2663 ms

Is there some cache I should clean ?

My go.mod file has

module foo

go 1.22.1

require github.com/aurelienpierreeng/ansel-doc v0.0.0-20240101153448-f48a3b8e779f // indirect

So change the version to whatever go version you have installed.

To clean your module cache:

hugo mod clean --all

Again, as a gut check on the content count, I added this to the config:

disableKinds = ['rss','sitemap','taxonomy','term']

result

                   | EN  | FR   
-------------------+-----+------
  Pages            | 209 | 207  
  Paginator pages  |   0 |   0  
  Non-page files   | 187 | 187  
  Static files     |  96 |  96  
  Processed images |   0 |   0  
  Aliases          |   2 |   1  
  Cleaned          |   0 |   0  

So I think we’re good.

Other things to check:

  1. Do you any module replacements set up?
  2. Have you vendored your modules?
  3. Did you add a bunch of content then forget to update the module locally (e.g., hugo mod get -u foo)?

Ok that did the trick. Your minimal example works here, thanks.

Remains to find out why my full project doesn’t.

No.

No idea what that means. I’m used to Git submodules, but the Hugo modules seem to work reversed so I’m mostly fighting my instincts all the time, and I wont pretend I understand what I’m doing.

Older Hugo versions build the website allright, so I don’t think it’s the module that is outdated. I’m suspecting something got deprecated or changed that makes my setup (built for 0.98) now invalid.

Did you type hugo mod vendor resulting in a _vendor directory in the root of your project?

Impossible to say from where I’m sitting. I suggest you compare the working setup that I shared to your setup.

1 Like

Now, I have. :smiley:

I found the culprit.

I had directly simlinked the local folder containing the docs to my website’s /content/doc folder, on top of the module mounting. That trick allowed me to write the docs (locally) and have the changes directly updated in the whole website dev server, without having to manually do a env HUGO_MODULE_REPLACEMENTS="github.com/aurelienpierreeng/ansel-doc -> ../../ansel-doc/" everytime.

This lazy trick has Hugo > 0.122 confused for some reason. In fairness, it was never clean.

Thanks for your help !

Should the _vendor subfolder be commited to the main website git repo ? My architecture is a bit convoluted since:

  • Doc website imports theme from main website module (disabling its own imports),
  • Main website imports (some) content from doc website (disabling its own imports),
  • Both websites are modules in themselves.

So, does the module providing the theme need to declare the _vendor for its children ?

  1. You don’t have to vendor (there are use cases where this is useful)
  2. But if you do, you need to commit it to Git or else it would be (mostly) useless
  3. You can run “hugo vendor” on any level.

Have a look at hugoDocs/hugo.work at master · gohugoio/hugoDocs · GitHub

Not that starting the server gets muchb shorter, but it’s much cleaner and works natively with Go modules with less surprises compared to the replace construct above.

In Hugo docs we vendor the theme (so we can include the full source in a tar ball in the Hugo binary distribution), so if I want to edit the theme I do:

 HUGO_MODULE_WORKSPACE=hugo.work hugo server --ignoreVendorPaths "**"
1 Like

Thanks. So “vendoring” means we make the modules visible and importable from a workspace script definition, (possibly having more than one workspace ?), but at the cost of duplicating the module code in the directory ?

Vendoring writes all of the modules’ dependencies to disk – so next time you build, the dependencies inside _vendor is used instead of going to e.g. GitHub and download it. This has its use cases (it makes a proect “self contained” so you can build it without network connection, you can zip the entire project and it will be buildable in 100 years after GitHub is gone etc.).

Workspaces is something different and mostly useful (I think) for local development of one or more modules:

3 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.