error: no go files found in root search path

[LandonTClipp]

This is a discussion thread for this error.

Documentation found here

[echarrod]

I have a repo where my main module I want to mock for is a few folders deep. I am getting this error when I place mockery.yaml at the root, even if I have go files at the root.

Is there a way I can keep this at the root, rather than in the sub-folder?

[LandonTClipp]

There is not, you have to place it at the location of the package you’re importing. The go package parser requires this or else it will not download the package unfortunately.

[fahminlb33]

I have the same issue. My solution to this is to create a new main func on my project root.

Project structure:

cmd
   /server
   /server/main.go
pkg
   /config
   /config/config.go
   /...
domain
   /users/...
   /products/...
   /...
test_spec.go --> to allow mockery to generate mocks

.mockery.yml

all: true
testonly: false
inpackage: true
with-expecter: true
dir: mocks/{{ replaceAll .InterfaceDirRelative "internal" "internal_" }}
packages:
    my-package:
        config:
            recursive: true

test_spec.go

package main

import "my-package/pkg/config"

// this is required to generate mock files
// this file is not used anywhere
func main() {
	config.Load("")
}

[dallindavis]

all: true
testonly: false
inpackage: true
with-expecter: true
dir: mocks/{{ replaceAll .InterfaceDirRelative "internal" "internal_" }}
packages:
    my-package:
        config:
            recursive: true

Using this pattern, how do I mock only select interfaces? I tried the following but no mocks are getting created.

all: true
testonly: false
inpackage: true
with-expecter: true
dir: mocks/{{ replaceAll .InterfaceDirRelative "internal" "internal_" }}
packages:
    my-package:
        config:
            recursive: true
        interfaces:
             MyInterface:

[sonalys]

Wouldn't it be possible to overcome the go pkg limitation by doing a recursive search, finding all sub directories that contains go files, and then run the command entrypoint for each individual hit?

[LandonTClipp]

Yes this is exactly what mockery does. Really though, read the linked docs. This is explained. The issue comes from when mockery parses the package metadata. The error comes from the Go package metadata parser, not mockery itself. It's not something that we can fix because the go package parser refuses to load metadata without a file present.

[LandonTClipp]

For more clarity, the reason why we cannot be separately loading the package metadata for each package found is because it will turn metadata parsing performance from a factor of N to NxM, where N is the number of dependencies in your project and M is the number of packages in your project. So for example if it takes 1 second to parse all dependencies in your project and you have 10 packages in your module, you have instantly changed the runtime from 1 second to 10 seconds. The main benefit of the packages feature that I released is that it called packages.Load once for the entire project instead of once per package. This is where the majority of the speed improvement comes from, and if we were to go back to the old way of doing this, it will tank performance.

Alternatively, there may be a way to have mockery auto detect this case and remove the package from the configuration so that it will never attempt to load the metadata for a package with no Go files. I feel pessimistic that this would work but if someone wants to try and make it work, I'd gladly merge the PR assuming there is no performance regression.

Also keep in mind, this is hard to get right in the general case. When mockery loads a package with the packages.Load call, if the package is not on local disk, Go will attempt to download it from the internet. If the package you specified has no Go file in the root, the package won't even be downloaded, so it is essentially impossible for mockery to perform a recursive search because Go failed to download it. The only way I can conceive of getting around this is if mockery takes care of downloading the package instead of relying on the tools provided by Go. I really hate this idea however.

So really, if you'd like to tackle this I'm all for it, but I went through the trouble many years ago and decided it wasn't worth it 🥲