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

[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.