FEEDBACK REQUESTED: packages feature

[LandonTClipp]

Update

2023-07-10

packages has been fully released! Thanks for the feedback and insights into how you use mockery. We can finally put this saga behind us and move on to more exciting ideas I have in mind.

2023-06-21

We are wrapping up with the packages feature. It has been in beta state with minimal issue for over a month now. When the time is right, I will consider this feature to be production ready.

Please view my blog post showcasing this new feature here: https://landontclipp.github.io/blog/2023/06/21/introducing-mockerys-new-packages-feature/

2023-05-14

As of v2.27.1, the packages feature has been moved to a beta state. We will leave it in this state for the next couple of months to allow for beta testing. Once it is moved out of beta, we will create a deprecation notice for the legacy configuration schema.

2023-04-06

The community has made it clear that automatic package discovery is a requirement as many projects have a large number of sub-packages. We will implement automatic package discovery before deprecating the old configuration style and removing the packages feature from alpha.

2023-03-09

As of v2.21.1, we now have the packages config section that can be used. See details of it here: https://vektra.github.io/mockery/features/#packages-configuration

Let me know your feedback and if there are any changes you'd like to be made! Note this feature is ALPHA, so it will likely have bugs and may have additions or subtractions to its feature set.

Description

We are adding a new feature in #548 that allows specifying explicit packages to generate mocks for, instead of the old method of dynamically discovering files on the filesystem using --all=True. The issue with the current style is multifaceted:

1. When using mockery --all, mockery will recursively iterate the filesystem and for each go file it finds, it will call packages.Load on just that file. This means that packages.Load will be called multiple times for every file in your package, which is an obvious redundancy. You could potentially fix this by caching the package.Load result on a per-directory, instead of a per-file level. This would cache the package.Load call once for a directory instead of multiple times, which could provide a performance benefit. However, the higher level picture is that dynamically discovering interfaces to mock is likely wasteful, as it's unlikely you would legitimately use every mock you've created.
2. The //go:generate directive is similarly wasteful under the current approach. Folks who use generate can likely get around some of the performance issues of (1) because they are generating mocks for a much smaller set of interfaces. For example, let's say you have a package with 5 files in it and 6 interfaces. If you used generate on all 6 of those interfaces, you'd be invoking mockery 6 separate times, which would redundantly call packages.Load 6 times. This would be a worse situation calling mockery once per file!
3. There is a general confusion about how to generate mocks for exterior packages. The behavior of mockery is not intuitive and likely breaks in many scenarios (Mockery follows type aliases and cannot compile mock #331). Using explicit definitions of what packages to load, which interfaces in those packages to mock, and per-mock configuration, all inside a single yaml file, would make the behavior far clearer and more targeted for the user's specific case.

What we propose is a yaml file like this:

packages:
  github.com/vektra/mockery/v2/pkg: 
    interfaces:
      TypesPackage:
      RequesterVariadic:
        config: 
          with-expecter: False 
        configs:
          - structname: RequesterVariadicOneArgument
            unroll-variadic: False
          - structname: RequesterVariadic
  io:
    config:
      all: True 
    interfaces:
      Writer:
        config:
          with-expecter: False 

The config provided to each interface would override package-level config, which would override defaults at the top-level.

This model of configuration is extremely powerful and opens a lot of doors for a high degree of customizability and flexibility.

You could emulate --all by doing:

packages:
  github.com/vektra/mockery/v2/pkg:
    config:
      all: True

However this would still only generate mocks for github.com/vektra/mockery/v2/pkg, not recursively iterate to sub packages.

Benefits this grants us

• Faster load times: packages.Load is called once for each package, instead of once per file in current scheme
• More targeted generations: only generate interfaces that you want/need
• More explicit behavior
• Easily generate mocks for any package inside or outside
• Differentiate how each mock is generated by using a tiered config strategy (global defaults, package-level defaults, interface-specific configs)
• Control over mock names, filenames, locations

Proposed Deprecation

We propose deprecating mockery --all, as this uses legacy package.Load behavior that causes slow mock generation. Additionally, deprecating this means we can remove a ton of legacy code that is a relic of the pre-go-module era. The packages config provides sufficient means for generating mocks for a package, which makes --all redundant. packages also adds a ton of new features that we get almost for free, and back porting those features to --all is an inefficient use of developer time.

Caveat

The one caveat of this is that it might make go:generate redundant. If you use the packages config in your repo but also use //go:generate mockery --name Stringer at some point in your repo, mockery would need to be explicitly aware of the fact that it's running under a generate directive and ignore the packages config. Otherwise it would try to generate all the packages you listed on every invocation of generate.

Questions To The Community

• Would this be useful to you?
• If this feature is included in the project, would you be okay with using this over the go:generate method of generating mocks?
• Would you be okay with this feature becoming the only way to define mocks?
• Thoughts on things that should be changed?

Current PR

#548

[SVilgelm]

The proposed changes are ok to me, i have only one question about the performance. This will not change the performance of the generated code, but the performance of the generator. So the question is who does really care about the generator's performance? I mean that i usually run it once in a while and commit the generated code to a repo.

So go ahead and don't forget to provide a documentation and/or examples.

[LandonTClipp]

That’s correct, it’s only the performance of the generator, not the generated code itself. I have had a number of people who have complained about the performance of the generator being problematic, especially for large repos. This can be mitigated by more targeted generation using go generate, but I got the sense that it was still unsatisfactory to people.

I don’t want to add a feature to solve a problem that is only a problem in theory and not practice. But, the performance improvement is really only one aspect of the benefits.

[SVilgelm]

But, the performance improvement is really only one aspect of the benefits.

agree, the more targeted generation is better. I think the recursive loader can be added later, like:

packages:
  github.com/vektra/mockery/v2/pkg:
    config:
      all: True
      recursive: True

[RangelReale]

About the generator performance, it would be beneficial for our CI jobs that are per-service, so for each service we generate the mocks again. This would be a great win for us, our mocks generation today takes almost 1 minute.

[LandonTClipp]

@RangelReale that's crazy! I'm glad to hear something like this would be beneficial.

[mattdowdell]

I'm ok with removing support for recursively discovering interfaces, but it's pretty useful to have automatic discovery of interfaces within a package.

For example, I have some generated clients from protobuf specs, and generate the mocks of those client interfaces for unit testing. Manually adding mocks for each interface is tedious, particularly as there's dozens of clients. A little bit of magic in detection here is much appreciated.

With regards to the finer control of which interfaces get mocks, there are times when I have mocks I don't want or need. But I'd say those undesirable mocks are in the minority, and I'm ok with them knocking around. The only ones that are slightly irksome are mocks for private interfaces that are output into a different package and so can't ever be imported. But those aren't a huge issue, and it looks like I could rename them with the proposed config anyway.

[LandonTClipp]

Discovery of all interfaces within a package would still be supported through something like this:

packages:
  github.com/vektra/mockery/v2/pkg:
    config:
      all: True

If you wanted to generate all mocks but modify the config for a specific one, you could do this:

packages:
  github.com/vektra/mockery/v2/pkg:
    config:
      all: True
    interfaces:
      Stringer:
        outputName: MockRenamedStringer

[RangelReale]

I'm testing this feature, one thing that I am missing is that currently my mocks are inside a "mocks" directory inside each package folder, but this don't seem to be possible currently, maybe adding a "PackageFolder" option to the templated directory and file name?

Current PackagePath has the complete module name like "github.com/XXX", but my local folder name doesn't contain this.

[RangelReale]

well, I was able to do this using a "dir" config inside each package manually, I guess this is not very easy to do generically.

[LandonTClipp]

I think the way to go here is to add a new RelativePackagePath variable or something like that so it places the mocks inside of your package. That should be fairly easy to do.

[jbub]

Playing around with this feature, in general it would be very useful to support some kind of defaults for all packages so that you do not have to repeat that for every package. For example now i need to specify outpkg manually for each package, it would be nice to have this as a default and use the template with something like {{ . PackageName }}. Generally, all the things should be customizable using templates with useful context like RelativePackagePath, PackageName and so on and ideally support global defaults and have options to customize on per package level. But i think this feature can be a game changer especially in big repos like ours where mock generation takes ages. Thanks!

[LandonTClipp]

For example now i need to specify outpkg manually for each package

This sounds like a bug. You are having to set the package name for each package? It should do that automatically. If it's not, please submit an issue as that's not intended.

Also, you can set each of these variables at the top-level of the yaml file. Perhaps this is a signal that I need to make the docs more clear.

[jbub]

Here is the summary of the problems i see now:

packages:
  github.com/jbub/mockdebug/abc/sub1/sub2:
    config:
      filename: "mock_{{.InterfaceName}}.go" # this works nicely
      dir: "abc/sub1/sub2"  # cant dir be autodected from package ?
      outpkg: sub2  # have to specify this otherwise it uses mocks package, but thats painful to specify for each package
      structname: "Mock{{.InterfaceName}}"  # cant use template here, also would be nice to specify globally not for each package
      all: True

[LandonTClipp]

I think all of what you specified is definitely doable, I'll work towards adding those features.

[jbub]

Nice, it improved a lot with the latest version, now i am able to do this:

dir: "{{.InterfaceDir}}"
filename: "mock_{{.InterfaceName}}.go"
structname: "Mock{{.InterfaceName}}"
with-expecter: true
packages:
  github.com/jbub/mockdebug/abc/sub1/sub2:
    config:
      all: True

There is other problem. I have a package like this:

package sub2

import (
	"context"
)

type Item struct {
}

type Repository interface {
	Get(context.Context, int32) (Item, error)
}

The generated mock looks like this. It adds this strange invalid import:

package sub2

import (
	context "context"

	sub1sub2 "github.com/jbub/mockdebug/abc/sub1/sub2" // this import is not valid
	mock "github.com/stretchr/testify/mock"
)

// MockRepository is an autogenerated mock type for the Repository type
type MockRepository struct {
	mock.Mock
}

// Get provides a mock function with given fields: _a0, _a1
func (_m *MockRepository) Get(_a0 context.Context, _a1 int32) (sub1sub2.Item, error) {
	ret := _m.Called(_a0, _a1)

	var r0 sub1sub2.Item
	var r1 error
	if rf, ok := ret.Get(0).(func(context.Context, int32) (sub1sub2.Item, error)); ok {
		return rf(_a0, _a1)
	}
	if rf, ok := ret.Get(0).(func(context.Context, int32) sub1sub2.Item); ok {
		r0 = rf(_a0, _a1)
	} else {
		r0 = ret.Get(0).(sub1sub2.Item)
	}

	if rf, ok := ret.Get(1).(func(context.Context, int32) error); ok {
		r1 = rf(_a0, _a1)
	} else {
		r1 = ret.Error(1)
	}

	return r0, r1
}

[LandonTClipp]

Hmm that's odd, I'll have to look into why it's doing that.

[rubencaro]

For us, all public interfaces need mocks. We are generating all mocks in a separate mocks folder, then mimicking the original package tree, and then deleting private interface's mocks:

mockery --all --keeptree --inpackage
rm -fr mocks/unneeded

This change sounds good, and will help better define which mocks we need and which we don't.

But we rely completely on the recursive discovery. Also performance is not a problem because of the reduced size of our services, so removing recursion adds no benefit for us. We would wait until something like this is added (like @SVilgelm suggested) before migrating:

packages:
  github.com/vektra/mockery/v2/pkg:
    config:
      all: True
      recursive: True

Or at least until you add something like @jbub proposal of supporting templates somehow.

In general, being forced to specify that for every package would be a usability problem for us.

[LandonTClipp]

Thanks for your perspective. It seems like right now there are two outstanding features that people need for this to be considered complete:

1. A way to mimic the package structure like in the --inpackage config option. PackagePath is not sufficient for people as this also includes the beginning parts of the name, like GitHub.com/vektra/mockery
2. A way to generate all sub packages recursively. I was hoping this was not going to be needed but I can see this being useful in cases where you have a lot of sub-packages.

[LandonTClipp]

{{.InterfaceDir}} template variable added in v2.21.6: #576

[RangelReale]

This worked perfectly for me!

with-expecter: True
dir: "{{.InterfaceDir}}/mocks"
outpkg: "mocks"
structname: "{{.InterfaceName}}"

[RangelReale]

in this case without outpkg the package name was not the expected mocks, it was the source package name, I had to add it to fix.

I think this may be a bug, as the documentation states:

mockery always generates files with the package mocks to keep things clean and simple. 

[LandonTClipp]

I modified the outpkg to default to the interface's package name but looking back at it, that's not the correct thing to do. Our default config is to generate mocks in a separate mocks/ folder so of course we would want the outpkg to be mocks. I will change that.

[arvenil]

I don't understand why this downgrade. Why do I need a config now? This worked perfectly as one-liner for go generate e.g. //go:generate mockery --all --output=./internal/mocks --exported --with-expecter. Why would I need global config file for something that is run per file/package/folder? Why do I have to specify every interface? Nobody has time for that, the auto-discovery was working perfectly fine. Performance was never a problem, running go generate ./... was never a problem as it's rare to generate all mocks in one go, and it never actually taken significant amount of time.

I love the lib so far, but the incoming changes seem to be a no-go for me.

[LandonTClipp]

Why do I need a config now?

The reason I am trying to do this is described in the description of this discussion.

Why do I have to specify every interface?

You don't have to specify every interface, this is clearly documented here: https://vektra.github.io/mockery/features/#packages-configuration

Performance was never a problem, running go generate ./... was never a problem as it's rare to generate all mocks in one go, and it never actually taken significant amount of time.

This may be true for you but I've had lots of people over the years complain about the poor performance. The solutions we present try to fix the issues that cause usability problems for people.

However, this is the point of this discussion to figure out how people use this package and what the general consensus is with what it should look like. Otherwise I don't really have any idea :) If people are generally strongly opposed to deprecating the old style of generation then we will not do that.

Nobody has time for that, the auto-discovery was working perfectly fine.

The only thing in this proposal that would change in regards to that would be that you specify the packages to mock in a config file instead of a go:generate directive. If you are using go:generate mockery once per package in your repo, then how would the config file be any different?

I am also considering having the recursive: True config option in packages, which would retain top-level "auto discovery". My original intent was to not allow auto-package-recursion (meaning we don't discover what packages you want mocked, you have to tell us), but it seems too many people find this useful. If we allow this option in config, would that be sufficient for you to move over to the config file?

[arvenil]

Yes. After discussion in another thread adding recursive: True LGTM. Thank you 🤗

[RangelReale]

One small pain point I felt is that we have a monorepo with many microservices and CODEOWNERS permissions for code review.

If I leave the entire mock configuration on the root of the repo, then people with root folder access would need to always review these changes, when today only the team responsible for the service needs to approve on a mock generation change.

It would be great if there was some way of "importing" configuration from other folders, but then we would have the problem of relative paths, and I look at the code, it doesn't seem to be easy to add such a thing. I'll need to think of how to handle this.

[LandonTClipp]

That's an interesting use case I did not think of, I will need to think about a way to do this. What if we just allowed it to work off of non-root project paths? We could ostensibly just have each mockery yaml file be independent of each other and you could have a //go:generate mockery inside each of your sub-packages that would read that package-specific config file. That might actually work out of the box, I would have to try it.

[RangelReale]

hmm yes, it probably would work, the only negative is that all the common packages/imports that all these services use will need to be reloaded again on each mockery run, negating some of the performance benefits of a single run.

[LandonTClipp]

That is true, although I suppose you would have had to do that anyway. In fact it’d still be worse in your current scheme because it would load the package once for every file, instead of in this scheme it would be once for every CODEOWNER location.

[RangelReale]

I was thinking of maybe having an include on the root configuration file, that would load "partial" configuration files from others folders, like:

{root}/mockery.yaml

with-expecter: True
dir: "{{.InterfaceDir}}/mocks"
outpkg: "mocks"
structname: "{{.InterfaceName}}"
includes:
  - service/httpserver
  - service/grpcserver

{root}/service/httpserver/mockery.partial.yaml

packages:
  github.com/vektra/mockery/v2/pkg:
    config:
      all: True
      recursive: True

but then it would need to know that this part of the configuration came from another folder so the relatives paths are different, should not be very easy...

[RangelReale]

I found an unexpected improvement on using the find method after I discovered that the xargs command has a parallel option (-P), so setting it for example as 5, I get 5 mock generations in parallel and it was much faster than any other option!

find . -type f \( -iname ".mockery.yaml" ! -path "./.go/*" \) | sed "s/.mockery.yaml//g" | xargs -t -P5 -I % sh -c 'cd %; go run github.com/vektra/mockery/v2@v2.23.1 || exit 255'

[arvenil]

After initial rant, this is my current config. I'm testing on version 2.22.1.

log-level: warn
disable-version-string: True
all: True
exported: True
with-expecter: True
output: ./internal/mocks

This works well with go generate:

//go:generate mockery
package main

But fails horribly if I ran mockery since it will generate all the mocks into the root folder with config /internal/mocks instead of each into sub package.

I've tried

log-level: warn
disable-version-string: True
all: True
exported: True
with-expecter: True
output: "{{.InterfaceDir}}/internal/mocks"

🙈

Would be nice to get it implemented ;d

[LandonTClipp]

And yes the config you posted is indeed what I envision it should look like, so that looks correct. It's just on me to implement the recursive option now.

[arvenil]

p.s.

The templates aren't available under the old schema (maybe I can make this backwards compatible, but it's not the priority at the moment)

This would be awesome as I could already try to drop //go:generate mockery completely and move to root config file - this could easy transition.

[arvenil]

p.p.s Another point, made somewhere else, if the recursive: True option is allowed it would be nice to have a way to add sub-config file, which would allow me to customize generator. Another option would be to read //go:generate mockery -some -flags line and respect used flags there :)

[arvenil]

I've tried using template variables again in the output for old method e.g. output: "{{.InterfaceDir}}/internal/mocks" and it doesn't work. This was not backported and you don't have plans to backport it?

It would help me to prepare for migration to packages as I could define global config already.

[LandonTClipp]

I don’t think I want to backport the templates because the functionality is too different from the legacy behavior and it would be hard to shoehorn that in.

[a-pedini]

In my own usecase I'd also be interested in keeping the recursive autodiscovery, we have a large project with a lot of subpackages... and if we're forced to use the packages configuration we'd probably have to write a tool ourselves to generate the configuration by walking our pkg folder...
I don't have a lot of experience in go projects but our internal convention is that we put all the package interfaces in the same interface.go file, so for us finding out the packages that needs mocking requires only finding all the interface.go files and getting the package name for each of them...
I'm not sure how common that is, but maybe using a regular expression to identify the filenames to check in the recursive autodiscovery could also help performance? in that case we'd just specify the root package and tell it to only check interface.go files...

[LandonTClipp]

Checking for a sentinel file is an interesting idea. I have been thinking about the best way to do this without tanking performance. One way was to simply find the first .go file during a directory walk and do a simple regex search for package foo, then use that as the package name. We can assume that all .go files in a directory are the same package, as that's part of the Golang spec. We'd have to be careful to consider cases where the package name is different from its directory name.

The way something like this could be practically implemented is simply discover the packages underneath the root, then inject those package names into the configuration map as if you had specified the packages manually. This would be a pretty clean way to do it.

As far as specifying a sentinel file, that could be an additional feature we could implement. I don't think the lack of that specific piece would block taking this out of alpha state, however.

It's pretty clear to me that auto-discovery is a requirement from the community, so naturally that will have to be implemented.

[RangelReale]

I also tried to implement the current packages method in my monorepo with multiple services, but as @a-pedini , having to add folder-by-folder (we use something like DDD, so each service has a lot of separation), wasn't really an improvement, I ended up with lots of 30+ line configurations, when just one "recursive" option per service would suffice.

Maybe an option of using in-source directives for each object to mock? Like

//mockery:mock

but I think a global autodiscovery would be good enough.

[jbub]

Been playing with v2.25.0 and it seems like the last puzzle missing for my usecase is the ability to change the mock name based on whether the original interface is exported/unexported. Maybe adding some flag to the template context would help:

mockname: "{{if .InterfaceExported}}Mock{{else}}mock{{end}}{{.InterfaceName}}"

[LandonTClipp]

I'll need to think about how I want to implement that. Obviously having an InterfaceExported variable would be easy to do, but I hope we could provide something else that doesn't require if/else statements in the template. Maybe an explicit {{.Mock}} variable that is sensitive to the exported-ness?

[jbub]

Or maybe have separate properties ?

mockname: 
  exported: "Mock{{.InterfaceName}}"
  unexported: "mock{{.InterfaceName}}"

[LandonTClipp]

@jbub I added the {{.Mock}} template variable, give that a shot when you get the chance.

[LandonTClipp]

@arvenil @RangelReale @jbub @rubencaro @mattdowdell @SVilgelm

I've put a bunch of effort into implementing the suggestions that have raised in this discussion. So far we have:

• A recursive option. This was actually a huge amount of work so I hope you like it! 😅
• A slew of additional templated variables
• Sensible defaults applied to all templated variables.
• Lots of other bug fixes found during development

Let me know what you think of the current iteration and if there is anything else you would want added. I decided that I'm not going to immediately implement the include: [other/mockery.yml] feature because I see that as more of a quality-of-life thing, but I'm open to having it in the future. For now though, I don't think it has to block packages.

If there's a general consensus on the current form, I'll take the feature into a beta state, where it'll probably reside for at least a few months.

[LandonTClipp]

I think I'll have to add that then!

[arvenil]

Thanks for the update.

Below works for me:

log-level: warn
disable-version-string: True
with-expecter: True
dir: "{{.InterfaceDir}}/internal/mocks"
mockname: "{{.InterfaceNameCamel}}"
filename: "{{.InterfaceName}}.go"
outpkg: "mocks"
packages:
  gitlab.com/my/pkg/subpkg_with_go_files:
    config:
      all: True
      recursive: True

However it's impossible to use it from root dir if there are no go files. Monorepo project has at root level go.mod but usually doesn't have any *.go files (eventually tools.go).

The go list -m correctly returns gitlab.com/my/pkg, I can use go test ./... or go test gitlab.com/my/pkg/... but mockery panics:

log-level: warn
disable-version-string: True
with-expecter: True
dir: "{{.InterfaceDir}}/internal/mocks"
mockname: "{{.InterfaceNameCamel}}"
filename: "{{.InterfaceName}}.go"
outpkg: "mocks"
packages:
  gitlab.com/my/pkg:
    config:
      all: True
      recursive: True

% mockery   
panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
github.com/vektra/mockery/v2/pkg/config.(*Config).subPackages(0x140001faa38?, {0x10347d150?, 0x1400024b740?}, {0x140001a85a0, 0x18}, 0x140001e8e00?)
        /Users/kdz/go/pkg/mod/github.com/vektra/mockery/v2@v2.28.0/pkg/config/config.go:441 +0x628
github.com/vektra/mockery/v2/pkg/config.(*Config).discoverRecursivePackages(0x10347d150?, {0x10347d150, 0x1400024b5c0})
        /Users/kdz/go/pkg/mod/github.com/vektra/mockery/v2@v2.28.0/pkg/config/config.go:544 +0x464
github.com/vektra/mockery/v2/pkg/config.(*Config).Initialize(0x10347b878?, {0x10347d150, 0x1400024b5c0})
        /Users/kdz/go/pkg/mod/github.com/vektra/mockery/v2@v2.28.0/pkg/config/config.go:110 +0x44
github.com/vektra/mockery/v2/cmd.(*RootApp).Run(0x140002704e0)
        /Users/kdz/go/pkg/mod/github.com/vektra/mockery/v2@v2.28.0/cmd/mockery.go:208 +0x3f4
github.com/vektra/mockery/v2/cmd.NewRootCmd.func1(0x14000232600?, {0x1032b5cd3?, 0x0?, 0x0?})
        /Users/kdz/go/pkg/mod/github.com/vektra/mockery/v2@v2.28.0/cmd/mockery.go:45 +0x54
github.com/spf13/cobra.(*Command).execute(0x14000232600, {0x14000190210, 0x0, 0x0})
        /Users/kdz/go/pkg/mod/github.com/spf13/cobra@v1.6.1/command.go:916 +0x5c4
github.com/spf13/cobra.(*Command).ExecuteC(0x14000232600)
        /Users/kdz/go/pkg/mod/github.com/spf13/cobra@v1.6.1/command.go:1044 +0x340
github.com/spf13/cobra.(*Command).Execute(...)
        /Users/kdz/go/pkg/mod/github.com/spf13/cobra@v1.6.1/command.go:968
github.com/vektra/mockery/v2/cmd.Execute()
        /Users/kdz/go/pkg/mod/github.com/vektra/mockery/v2@v2.28.0/cmd/mockery.go:106 +0x20
main.main()
        /Users/kdz/go/pkg/mod/github.com/vektra/mockery/v2@v2.28.0/main.go:8 +0x1c

This means I'm sadly still stuck to old, non-packages method.

p.s. I've tried to put gitlab.com/my/pkg/..., not expecting much though :) Just a comment that the ... notation could be considered as alternative to recursive: True.

% mockery
24 May 23 17:46 CEST WRN BETA FEATURE: use of the 'packages' config variable is currently in a beta state. Use at your own risk. discussion=https://github.com/vektra/mockery/discussions/549 dry-run=false version=v2.28.0
Error: unable to get map config for package: package not found in config

EDIT: If I add dummy go file it works and is blazing fast!:

% cat whatever.go 
package main

So it looks like this should be possible to fix - can't wait until final release!

[LandonTClipp]

@arvenil you’re actually the second person to note issues with the lack of go files in the root dir. I think I should fix this. Mockery does use the presence of a go file to determine if the directory is a package or not which is maybe not entirely correct but I wanted to avoid calling out to go list as that was the source of performance issues.

[LandonTClipp]

Actually, the simple solution is to search for go.mod and *.go, that would fix it.

[LandonTClipp]

@arvenil I tried to fix this but realized it wasn't as simple as I had hoped. The issue comes from the fact that https://pkg.go.dev/golang.org/x/tools/go/packages does not return any metadata on where the package is located on-disk if the package contains no go files. I could not find a way around this no matter what parsing options I specified.

I added clear logs in this case and documented the fix in #637. Hopefully that should be enough. I also hope someone can find the solution, but I fear there may not be.

[RangelReale]

I implemented this in my monorepo, because of the CODEOWNERS issue I had to create a config file per microservice, didn't use the recursive option in this case, and together with using find/xargs -P5, I've got a great speed up on the generation!

It's much more organized this way also, we have more control of the generation process.

[LandonTClipp]

Great to hear. I'm open to making the CODEOWNERS situation easier to deal with through your include: [] suggestion, but I hope you'll get enough lift with the current implementation.

[LandonTClipp]

Closing this discussion as the feature is quite mature now. Thanks for the discussions everyone.