Version mismatch when specifying module version

support
1

Hey folks, hope everyone’s doing well.

I was testing Hugo Modules with version pinning and noticed the version ends up different across hugo.toml, go.mod, and _vendor. Not sure if this is expected or if I missed something in the workflow.

Steps to Reproduce

hugo new site mynewsite
cd mynewsite

cat << EOF >> hugo.toml
[module]
[[module.imports]]
path = 'github.com/spf13/hyde'
version = 'v1.3.0'
EOF

hugo mod init foo
hugo mod get
hugo mod vendor

Results

go.mod

require github.com/spf13/hyde v1.4.1 // indirect

go.sum

github.com/spf13/hyde v1.4.1 h1:sOpc9qSQxi+MhMOMl9p2Ne9pFt3zN4doxekzFBYfCYs=
github.com/spf13/hyde v1.4.1/go.mod h1:CSmLWCbXXInaA5zAkwAQ0EbwpR7Pe74eSmDxdGspoCY=

❯ hugo mod graph
project github.com/spf13/hyde@v1.3.0+vendor

❯ go mod graph
foo github.com/spf13/hyde@v1.4.1
foo go@1.25.5
go@1.25.5 toolchain@go1.25.5

Actual _vendor directory

❯ ls _vendor/github.com/spf13
hyde@v1.3.0

❯ cat _vendor/modules.txt
# github.com/spf13/hyde@v1.3.0 v1.3.0

Did I miss a step somewhere?

2

The way I read the documentation and the PR with that feature that versioned module is NOT managed via Golang but directly via GoHugo. So having go.mod/sum showing a wrong version might point to it not knowing about your version setup. All other commands show the right version from your config.

Does it work? Then it might be “just a little inconvenience”.

3

Got it, thanks! This should be expected behavior then.

4

The confusion arises when you start with a versioned import then switch to a non-versioned import, or vice versa.

5

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