Sudden VS Code Problem with my go.mod file (not seen before)

burke.brunson · February 21, 2025, 7:34pm

My Hugo Blox template Hugo site currently builds locally and in production with no issue after I updated to Go v1.24 and Hugo v0.144.2. However, I ran into something new in the VS Code “Problems” window for the go.mod file dealing with line 1, module [url]. Here is the “Problem” listed by Vs Code:

[{
	"resource": "part/of/path/obscured/for/privacy/go.mod",
	"owner": "_generated_diagnostic_collection_name_#5",
	"severity": 8,
	"message": "packages.Load error: err: exit status 2: stderr: panic: LoadImport called with empty package path [recovered]\n\tpanic: LoadImport called with empty package path\n\ngoroutine 1 [running]:\ncmd/go/internal/load.(*preload).flush(0xc0005968f0)\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:1128 +0x6a\npanic({0x925f140?, 0x9343540?})\n\t/usr/local/Cellar/go/1.24.0/libexec/src/runtime/panic.go:787 +0x132\ncmd/go/internal/load.loadImport({0x934bf80, 0x9787d60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, 0x0, {0x50708855, ...}, ...)\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:717 +0x1530\ncmd/go/internal/load.(*Package).load(0xc000067808, {0x934bf80, 0x9787d60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, {0xc0003ec080, ...}, ...)\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:2035 +0x24ce\ncmd/go/internal/load.loadImport({0x934bf80, 0x9787d60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, 0xc0005968f0, {0xc0003ec080, ...}, ...)\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:780 +0x52f\ncmd/go/internal/load.PackagesAndErrors({0x934bf80?, 0x9787d60?}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, {0xc0000b23f0, 0x2, ...})\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:2920 +0xa33\ncmd/go/internal/list.runList({0x934bf80, 0x9787d60}, 0xc0000b08a0?, {0xc0000b23f0, 0x2, 0x2})\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/list/list.go:618 +0xc6a\nmain.invoke(0x9757b20, {0xc0000b2350, 0xc, 0xc})\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/main.go:341 +0x845\nmain.main()\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/main.go:220 +0xe8b",
	"source": "go list",
	"startLineNumber": 1,
	"startColumn": 1,
	"endLineNumber": 1,
	"endColumn": 59
}]

In the template I use, the module listed on line 1 for the website can be named whatever you like since it isn’t imported and Hugo doesn’t use these details - users often change it to match their own repo name. I tried doing exactly that to see if it would fix the issue, but I get the same “Problem” thrown by VS Code.

Does anyone know what might be happening, suddenly, to have an error thrown for line 1 of go.mod after Hugo and Go were updated to the latest versions?

jmooring · February 21, 2025, 7:40pm

Do you see “problems” with this go.mod file?

module github.com/jmooring/test

go 1.24.0

require github.com/jmooring/hugo-module-content v0.1.9 // indirect

burke.brunson · February 21, 2025, 7:51pm

I do still see a “Problem” thrown. Attaching a screenshot for confirmation along with the thrown “Problem” message.

[{
	"resource": "part/of/path/obscured/for/privacy/go.mod",
	"owner": "_generated_diagnostic_collection_name_#5",
	"severity": 8,
	"message": "packages.Load error: err: exit status 2: stderr: panic: LoadImport called with empty package path [recovered]\n\tpanic: LoadImport called with empty package path\n\ngoroutine 1 [running]:\ncmd/go/internal/load.(*preload).flush(0xc0005a7e50)\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:1128 +0x6a\npanic({0x10e33140?, 0x10f17540?})\n\t/usr/local/Cellar/go/1.24.0/libexec/src/runtime/panic.go:787 +0x132\ncmd/go/internal/load.loadImport({0x10f1ff80, 0x1135bd60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, 0x0, {0x18239855, ...}, ...)\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:717 +0x1530\ncmd/go/internal/load.(*Package).load(0xc000591808, {0x10f1ff80, 0x1135bd60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, {0xc0005a4d40, ...}, ...)\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:2035 +0x24ce\ncmd/go/internal/load.loadImport({0x10f1ff80, 0x1135bd60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, 0xc0005a7e50, {0xc0005a4d40, ...}, ...)\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:780 +0x52f\ncmd/go/internal/load.PackagesAndErrors({0x10f1ff80?, 0x1135bd60?}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, {0xc0000ba3f0, 0x2, ...})\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:2920 +0xa33\ncmd/go/internal/list.runList({0x10f1ff80, 0x1135bd60}, 0xc0000b88a0?, {0xc0000ba3f0, 0x2, 0x2})\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/list/list.go:618 +0xc6a\nmain.invoke(0x1132bb20, {0xc0000ba350, 0xc, 0xc})\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/main.go:341 +0x845\nmain.main()\n\t/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/main.go:220 +0xe8b",
	"source": "go list",
	"startLineNumber": 1,
	"startColumn": 1,
	"endLineNumber": 1,
	"endColumn": 59
}]

jmooring · February 21, 2025, 7:54pm

Something unique to your environment. No problems here.

burke.brunson · February 21, 2025, 8:13pm

I tried disabling the Prettier formatter extension, and nothing changed with the VS Code “Problem.” Then, I tried disabling the Go Official Rich Language Support extension, and it took the “Problem” away. Of course, it also disabled the language support, but at least the error is not thrown any more… Attaching screenshot of my go.mod.

Perhaps, the official Go language support extension hasn’t been updated yet? Or…I don’t know…I think I’ve actually been running v1.24 since it came out, but the “Problem” just started showing up today…

If you have any other thoughts, I’d really appreciate it.

davidsneighbour · February 21, 2025, 11:30pm

That’s the problem with screenshots, they don’t tell the whole story.

Is it a Go Module File as filetype? (visible in the status bar) - my guess (black box) is “no”, because if it would be the file type it would show different colors for module and the url
What other plugins are installed that tinker with Go and go.mod files
What is the output of Output > Go, Output > other go plugins/extensions. Not one line only, but the full output from start of the IDE to the error when opening the go.mod file.
Are you “doing” anything with Go on your workstation? Like specific configurations, testing GoHugo, compiling binaries, etc… is there a go.work file somewhere in the website repo? Remove it.
Can your Golang binary reach github.com? That’s what that error sounds like. What happens on hugo mod get -u ./... on CLI? any error messages? Is VSCode using the same golang binary that the CLI is using?
Can you configure your VSCode to use a different Go binary and does the issue persist then? I remember my VSCode downloading its own Golang binaries.

It’s probably best to remove the Go extension, then clean your config (.vscode folder, *.workspace file, global user config) from anything extension related and then reinstall.

To start you could create a new profile without any extension and without copying default settings over, then install the golang extension, open your website repo and see what happens. If it all works fine >> add one extension per time until you found the culprit

burke.brunson · February 22, 2025, 6:19am

Update 2025-02-22 01:16 CT (07:16 UTC): I deleted the local instances of Hugo and Go that I manually downloaded and set up within my local website repo (the ones not installed by Homebrew). After doing that, the “Problem” thrown by VS Code from whatever error was happening with the Official Go Extension no longer exists. I had the Hugo binary installed in a bin folder, and the extracted go folder was placed at the top level of the repo. I’ve verified that the latest versions are what was downloaded from the Go site (v.1.24.0) and Hugo GitHub repo (v0.144.2). Each time I put the files back, the Problem comes back, and each time I remove them, it goes away.

Is there an issue doing this or doing it this way (having local Hugo/Go in your website repo that is outside of source control)? Is there a better way to save the Hugo binary and Go Folder in a website repo, so local testing can be done without the Homebrew global instances? I asked an LLM, and it seems to think it should be OK to simply exclude those folders from the Go Extension scanning to remove the problem… I just looked in a newly extracted Go download, and there is, indeed, a go.mod file in the misc folder and src folder as well as some others, so maybe the scan is picking those up, too…

Yes, VS Code auto-detects it as a “Go Module File” type (confirmed on Status Bar). The reason you don’t see different colors for module and the url is that the last screenshot I posted had the Go Language Support Extension turned off. If you look at the first svreenshot I posted, there are different colors, although it may be difficult to see that with my dark theme. Look closely, and you’ll see it.
None.
All Output of Go Extension, from VS Code start to opening go.mod:

2025-02-21 23:03:13.799 [info] Try to start language server - activation (enabled: true)
2025-02-21 23:03:14.027 [info] Running language server gopls(v0.17.1/go1.24.0)

However, the “gopls (server)” [Go’s language server] Output shows the following after freshly opening Vs Code and, then, opening the go.mod file:

[Info  - 11:47:13 PM] 2025/02/21 23:47:13 Created View (#1)
	directory=/Users/bb-mbpro/Documents/_github/burkebrunson.github.io
	view_type="GoMod"
	root_dir="file:///Users/bb-mbpro/Documents/_github/burkebrunson.github.io"
	go_version="go version go1.24.0 darwin/amd64"
	build_flags=[]
	env={GOOS:darwin GOARCH:amd64 GOCACHE:/Users/bb-mbpro/Library/Caches/go-build GOMODCACHE:/Users/bb-mbpro/go/pkg/mod GOPATH:/Users/bb-mbpro/go GOPRIVATE: GOFLAGS: GO111MODULE: GOTOOLCHAIN:auto GOROOT:/usr/local/Cellar/go/1.24.0/libexec GoVersion:24 GoVersionOutput:go version go1.24.0 darwin/amd64
 ExplicitGOWORK: EffectiveGOPACKAGESDRIVER:}
	env_overlay=[]

[Info  - 11:47:14 PM] 2025/02/21 23:47:14 Created View (#2)
	directory=/Users/bb-mbpro/Documents/_github/todo
	view_type="AdHoc"
	root_dir="file:///Users/bb-mbpro/Documents/_github/todo"
	go_version="go version go1.24.0 darwin/amd64"
	build_flags=[]
	env={GOOS:darwin GOARCH:amd64 GOCACHE:/Users/bb-mbpro/Library/Caches/go-build GOMODCACHE:/Users/bb-mbpro/go/pkg/mod GOPATH:/Users/bb-mbpro/go GOPRIVATE: GOFLAGS: GO111MODULE: GOTOOLCHAIN:auto GOROOT:/usr/local/Cellar/go/1.24.0/libexec GoVersion:24 GoVersionOutput:go version go1.24.0 darwin/amd64
 ExplicitGOWORK: EffectiveGOPACKAGESDRIVER:}
	env_overlay=[]

[Info  - 11:47:14 PM] 2025/02/21 23:47:14 go/packages.Load #2
	view_id="2"
	snapshot=0
	directory=/Users/bb-mbpro/Documents/_github/todo
	query=[./ builtin]
	packages=2
	duration=139.200001ms

[Info  - 11:47:14 PM] 2025/02/21 23:47:14 Created View (#3)
	directory=/Users/bb-mbpro/Documents/_github/burkebrunson
	view_type="AdHoc"
	root_dir="file:///Users/bb-mbpro/Documents/_github/burkebrunson"
	go_version="go version go1.24.0 darwin/amd64"
	build_flags=[]
	env={GOOS:darwin GOARCH:amd64 GOCACHE:/Users/bb-mbpro/Library/Caches/go-build GOMODCACHE:/Users/bb-mbpro/go/pkg/mod GOPATH:/Users/bb-mbpro/go GOPRIVATE: GOFLAGS: GO111MODULE: GOTOOLCHAIN:auto GOROOT:/usr/local/Cellar/go/1.24.0/libexec GoVersion:24 GoVersionOutput:go version go1.24.0 darwin/amd64
 ExplicitGOWORK: EffectiveGOPACKAGESDRIVER:}
	env_overlay=[]

[Info  - 11:47:14 PM] 2025/02/21 23:47:14 go/packages.Load #3
	view_id="3"
	snapshot=0
	directory=/Users/bb-mbpro/Documents/_github/burkebrunson
	query=[./ builtin]
	packages=2
	duration=86.202735ms

[Error - 11:47:16 PM] 2025/02/21 23:47:16 go/packages.Load #1: err: exit status 2: stderr: panic: LoadImport called with empty package path [recovered]
	panic: LoadImport called with empty package path

goroutine 1 [running]:
cmd/go/internal/load.(*preload).flush(0xc00030f210)
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:1128 +0x6a
panic({0xb036140?, 0xb11a540?})
	/usr/local/Cellar/go/1.24.0/libexec/src/runtime/panic.go:787 +0x132
cmd/go/internal/load.loadImport({0xb122f80, 0xb55ed60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, 0x0, {0x1243c855, ...}, ...)
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:717 +0x1530
cmd/go/internal/load.(*Package).load(0xc0002fa608, {0xb122f80, 0xb55ed60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, {0xc0004de180, ...}, ...)
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:2035 +0x24ce
cmd/go/internal/load.loadImport({0xb122f80, 0xb55ed60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, 0xc00030f210, {0xc0004de180, ...}, ...)
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:780 +0x52f
cmd/go/internal/load.PackagesAndErrors({0xb122f80?, 0xb55ed60?}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, {0xc0000b23f0, 0x2, ...})
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:2920 +0xa33
cmd/go/internal/list.runList({0xb122f80, 0xb55ed60}, 0xc0000b08a0?, {0xc0000b23f0, 0x2, 0x2})
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/list/list.go:618 +0xc6a
main.invoke(0xb52eb20, {0xc0000b2350, 0xc, 0xc})
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/main.go:341 +0x845
main.main()
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/main.go:220 +0xe8b

	view_id="1"
	snapshot=0
	directory=/Users/bb-mbpro/Documents/_github/burkebrunson.github.io
	query=[/Users/bb-mbpro/Documents/_github/burkebrunson.github.io/... builtin]
	packages=0
	duration=2.173436726s

[Error - 11:47:16 PM] 2025/02/21 23:47:16 initial workspace load failed: packages.Load error: err: exit status 2: stderr: panic: LoadImport called with empty package path [recovered]
	panic: LoadImport called with empty package path

goroutine 1 [running]:
cmd/go/internal/load.(*preload).flush(0xc00030f210)
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:1128 +0x6a
panic({0xb036140?, 0xb11a540?})
	/usr/local/Cellar/go/1.24.0/libexec/src/runtime/panic.go:787 +0x132
cmd/go/internal/load.loadImport({0xb122f80, 0xb55ed60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, 0x0, {0x1243c855, ...}, ...)
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:717 +0x1530
cmd/go/internal/load.(*Package).load(0xc0002fa608, {0xb122f80, 0xb55ed60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, {0xc0004de180, ...}, ...)
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:2035 +0x24ce
cmd/go/internal/load.loadImport({0xb122f80, 0xb55ed60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, 0xc00030f210, {0xc0004de180, ...}, ...)
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:780 +0x52f
cmd/go/internal/load.PackagesAndErrors({0xb122f80?, 0xb55ed60?}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, {0xc0000b23f0, 0x2, ...})
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:2920 +0xa33
cmd/go/internal/list.runList({0xb122f80, 0xb55ed60}, 0xc0000b08a0?, {0xc0000b23f0, 0x2, 0x2})
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/list/list.go:618 +0xc6a
main.invoke(0xb52eb20, {0xc0000b2350, 0xc, 0xc})
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/main.go:341 +0x845
main.main()
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/main.go:220 +0xe8b


[Info  - 11:47:43 PM] 2025/02/21 23:47:43 background imports cache refresh starting

[Info  - 11:47:44 PM] 2025/02/21 23:47:44 background imports cache refresh starting

[Info  - 11:47:44 PM] 2025/02/21 23:47:44 background refresh finished after 28.990102ms

[Info  - 11:47:44 PM] 2025/02/21 23:47:44 background refresh finished after 415.121878ms

[Info  - 11:47:44 PM] 2025/02/21 23:47:44 background imports cache refresh starting

[Info  - 11:47:44 PM] 2025/02/21 23:47:44 background refresh finished after 15.658718ms

[Error - 11:47:51 PM] 2025/02/21 23:47:51 errors loading workspace: packages.Load error: err: exit status 2: stderr: panic: LoadImport called with empty package path [recovered]
	panic: LoadImport called with empty package path

goroutine 1 [running]:
cmd/go/internal/load.(*preload).flush(0xc00030f210)
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:1128 +0x6a
panic({0xb036140?, 0xb11a540?})
	/usr/local/Cellar/go/1.24.0/libexec/src/runtime/panic.go:787 +0x132
cmd/go/internal/load.loadImport({0xb122f80, 0xb55ed60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, 0x0, {0x1243c855, ...}, ...)
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:717 +0x1530
cmd/go/internal/load.(*Package).load(0xc0002fa608, {0xb122f80, 0xb55ed60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, {0xc0004de180, ...}, ...)
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:2035 +0x24ce
cmd/go/internal/load.loadImport({0xb122f80, 0xb55ed60}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, 0xc00030f210, {0xc0004de180, ...}, ...)
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:780 +0x52f
cmd/go/internal/load.PackagesAndErrors({0xb122f80?, 0xb55ed60?}, {0x0, 0x1, 0x0, 0x1, 0x1, 0x0}, {0xc0000b23f0, 0x2, ...})
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/load/pkg.go:2920 +0xa33
cmd/go/internal/list.runList({0xb122f80, 0xb55ed60}, 0xc0000b08a0?, {0xc0000b23f0, 0x2, 0x2})
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/internal/list/list.go:618 +0xc6a
main.invoke(0xb52eb20, {0xc0000b2350, 0xc, 0xc})
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/main.go:341 +0x845
main.main()
	/usr/local/Cellar/go/1.24.0/libexec/src/cmd/go/main.go:220 +0xe8b

	view_id="1"
	snapshot=1
	directory=/Users/bb-mbpro/Documents/_github/burkebrunson.github.io

I searched my website repo. There is no go.work file. I am not doing anything other than maintaining my personal Hugo website an incrementally updating Hugo and its Go dependency as new releases come forth.
I am not certain if it can reach github.com (?). Everything about the template I use is operating as it should, and the website builds locally and when deployed in production. That’s as far as I get with that. When I run the command, everything runs fine. Yes, the same binary is used.
I use homebrew to install Hugo and Go globally, and I also have regularly placed a copy of the latest Hugo and Go in my website repo (outside of source control) in order to do initial testing for updates using a new branch each time. I am able to change PATH in a VS Code terminal session in order to be able to use both instances of Hugo and Go, as needed. Running go version on both instances shows a return of go version go1.24.0 darwin/amd64.

I’ve tried disabling individual Go and Hugo extensions. None of them removed the error except disabling/uninstalling the Go Official Extension. However, on my “Default” profile, if I uninstall it and reinstall it, the “Problem” output persists. I did not see any Go-Extension-specific things except a tools auto updater in the VS Code settings.json.

I created a new “Test” VS Code profile, and ran which go to get a return of /usr/local/bin/go (where Homebrew installs it) and go version to get a return of go version go1.24.0 darwin/amd64 and installed only the Go Rich Language Support Extension and the Vs Code “Problem” came back up again, without any other VS Code extensions installed.

system · February 24, 2025, 6:20am

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

Topic		Replies	Views
Strange module issue support modules	2	363	January 12, 2024
Hugo mod vendor: not working on Windows (v0.116.0) support	7	515	August 3, 2023
Go.sum and hugo mod cleanup support	5	1580	March 22, 2022
Golang newbie - keen to contribute support	7	2874	October 14, 2021
Go mod init and go mod tidy support	2	1054	March 26, 2024

Sudden VS Code Problem with my go.mod file (not seen before)

Related topics