Open grddev opened 7 months ago
Not reproduce. I think it is more a nvim setup.
Not reproduce. I think it is more a nvim setup.
Interesting. Is your nvim setup to automatically change directory based on file? If you run :pwd
does that include the mod1
folder or not?
EDIT: For me, the :GoTestFile
command works only when nvim:s :pwd
is in the mod1
directory, and otherwise not.
The test file folder is auto-detected. One thing you can try is using the minium setup in playground folder
cd go.nvim/playground/sampleApp
nvim -u ../init_lazy.lua pkg/findAllSubStr_test.go
GoTestFile -F
So in that case the go.mod
file is in the :pwd
directory. If move the module to a subdirectory as per my instructions above, if I updated the above instructions to be the following, it fails
cd go.nvim/playground/sampleApp
mkdir x
mv go.* *.go pkg x
HOME=$(mktemp -d) nvim -u ../init_lazy.lua x/pkg/findAllSubStr_test.go
GoTestFile -F
Note that I added HOME=$(mktemp -d)
to ensure that none of my default nvim configuration was loaded, so this should be with exactly the configuration from init_lazy.lua
.
Technically, it first failed with a different error as I no longer had gopls
installed and it then it instead tried to run go test x/pkg
instead of go test ./pkg
, but with gopls
installed, this fails the same way as described in previous comments.
Ok, I understand what happened. Pushed an fix for it.
I'm not too familiar with lua scripting in nvim, but it looks like this just changes the directory, without changing back afterwards. In my environment that would cause other things to break. Ideally, you'd want to pass the workspace folder as the cwd argument of uv.spawn()
in order to not actually change the cwd of nvim itself at all.
I think it's a bug with GitHub. It refers to PR 402 instead of Issue 402 in the previous comments
Creating a sample repository with a nested module and opening the main project folder as below
Opening
mod1/main_test.go
in nvim (without switching directory) and running:GoTestFile
runs the expected commandgo test . -run TestX
, but it fails as it runs it from the mainproject
directory instead of themod1
directory. Adding a:cd mod1
before running the tests makes everything work, but is somewhat inconvenient, and given that the plugin has already figured out that the module path is.
it seems like it already knows about the location of thego.mod
file and thus could also run the tests from that directory.