modules: Check replacements in config vs replace in go.mod for transitive dependency changes

[bep]

Currently, if you have:

project => mod1 => mod2

And add replacements directive in your config.toml for mod1 (to edit it manually). If you then updates the Git ref from mod1 => mod2 to a different version, that version does not get picked up -- the replacements directive is for that module only and not its imports.

You will get the truth when running go mod graph, but this is different from doing the same with a replace directive in go.mod.

When you really think about it this may not be that surprising, and I'm not sure we can do more than to document it better -- but we need to think.

[davidsneighbour]

I have all my redirects in the root module, even those for those requires in mod1 and mod2. Not sure if I misunderstand the issue at hand, but this way it works for me on updates further down the labyrinth. And then, in my release scripts I run a recursive update in all modules on whatever level. Before I had redirects per module requirement and often the updates did not come through. It gets messy if more modules receive updates in one go.

The release script does:

• remove redirects
• do a recursive update
• release
• add redirects

[dkipp]

is this the same issue? https://discourse.gohugo.io/t/how-to-do-hugo-0-77-module-replacements-with-nested-modules-right/34225

same setup:

project => mod1 => mod2

When module.replacements is set in project for mod1 to a local directory, hugo and hugo server are no longer working

[istr]

@dkipp

is this the same issue? https://discourse.gohugo.io/t/how-to-do-hugo-0-77-module-replacements-with-nested-modules-right/34225

same setup:

project => mod1 => mod2

When module.replacements is set in project for mod1 to a local directory, hugo and hugo server are no longer working

I would tend to say "yes". My expectation would be that HUGO_MODULE_REPLACEMENTS (env) as well as replacements (in the configuration of the main project) behave exactly like an entry in the main project's go.mod in this scenario. This is currently not the case and my understanding is that this issue addresses the same deviation.

The problem that hugo mod graph fails to resolve the dependency, even if the local mod 1 (replaced) refers to the same version of mod 2, seems to be closely related.

That is to say hugo mod graph works and something like HUGO_MODULE_REPLACEMENTS='github.com/foo/mod-1 -> ../mod-1' hugo mod graph fails in this situation because mod 2 could not be resolved anymore. The same replacement in go.mod does the job.

@bep why do you come to the conclusion:

and I'm not sure we can do more than to document it better

where do you see the difficulty of the change?

[tnarik]

perhaps I'm misreading the documentation ( https://github.com/golang/go/wiki/Modules#gomod ) or this issue, but I think 'replace' only applies to the top level module, and so replacements in hugo.toml (for instance) is behaving currently example the same way as replace in go.mod.

that is consistent with the tests I was running in my setup ( project => compound theme (locally) => custom theme modifications (locally). I had to use replace in the go.mod for the project.