So, just like in that thread, what is the output of hugo config mounts. What is the content of the configurations of all three modules. Can you put a sample repository online.
The short answer is that yes, you can use nested modules (import a module that itself imports modules). (I’m going that with one of my repos at this very moment). @davidsneighbour’s questions will help figure out what is going wrong, but it’s not simply nesting that is the problem.
You should be able to just clone the top one, run “hugo mod get -u ./…”
and see that the icon repositories (from config in test-nested-modules) don’t show up in “hugo config mounts” and in go.mod, only test-theme is listed.
Is the main problem that the vendoring doesn’t bring everything up to the top-level site? If that’s the case I would also modularize the bootstrap and font-awesome repos
I am trying to add them as modules so they they can be accessed in “test-site”.
My problem is the config for these nested modules doesn’t seem to be filtering down to “test-site”
If that is your intent you need to actually fork the repos and make them hugo modules.
(That is hugo mod init and any config.toml (or equivalent).
AFAIK pulling in a non-module repo as a module won’t work, at least not with hand-coded ‘mounts’. It might work in a ‘pure import’ scenario, but I’m not sure.
I’ve run into this myself where I tried to import non-module and it just did not work.
I’ll see about a full demo soon.
I’m remembering now that I’m working on it, is that part of the issue is that go modules have specific expectations about versioning (tags). Will post more later.
Also, because you have an ‘assets’ source mount you won’t see sources below ‘assets’, IIRC, within that repo. (with hugo config mounts). Order may matter.
Hmmm… I was wrong on that. I have more testing to do, I guess. (I’ve had trouble with non-Hugo modules in the past, but it’s probably something else that was going on, given that it works for you).
ignoreConfig
If enabled, any module configuration file, e.g. config.toml, will not be loaded. Note that this will also stop the loading of any transitive module dependencies.
I believe this is what is messing you up. I see why given font-awesomes’s defaults, but I will have to check @pointyfar’s repo to see how they handle it.
The @5.15.3 thing reminds me of what the problem was with non-Hugo (non-Go) modules – hugo mod get -u ./… will consistently fetch the wrong version of font-awesome in the current circumstance. The only way to fix that issue is to fix the tags in the repo you use to be compatible with Hugo/Go modules (I think it would be enough to eliminate all the vx.x.x tags from the repo, and just used the latest master). Go version module versioning is a pain especially with non-Go repos.
I have moved the “test-nested-module” config file into the root of the site.
I have manually updated the font-awesome repository specifying the non-standard version.
It’s finally working. I realised that I didn’t understand the solution in the previous issue.
I’ll note it in the docs so its clear that only the top level site can use a config DIR.
Have you personally had any luck with (local) module replacements via the config files?
I can see that the path needs to be relative to the theme directory, but when modules are nested, I am assuming that the path is being resolved relative to the parent site module rather than the nested module.
FWIW using the HUGO_MODULE_REPLACEMENTS environment variable works for me (with absolute paths). I know it’s not quite what you asked, but I am not a fan of committing local paths into repos, so I never use the config file replacements.