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.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open. If this is a feature request, and you feel that it is still relevant and valuable, please tell us why. This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.