Will the go:generate approach still work in version v3?

[spirin]

I'm a big fan of mockery. I work at a large company where some teams use uber's mock library, and others use mockery. If the go:generate approach stops working, it will be very difficult for me to keep fighting for mockery for several reasons.

Centralized solutions are always problematic in large projects:

1. In a large service with multiple teams, writing mocks into a single config file leads to constant merge conflicts.
2. In such large services, centralized, one-command generation is not needed. Instead, developers typically generate a single mock for their interface and commit it independently, without interfering with others. The common workflow is simple: write the interface, add a //go:generate line, the IDE turns it into a clickable link, click it — and the mock is generated. Fast and convenient.
3. Hardcoding package names is bad practice. Codebases grow and evolve, and having to constantly update configuration files along with package changes is undesirable.

I really hope the go:generate approach remains supported, because otherwise, at least in our case, migrating to v3 won’t be an option.

[LandonTClipp]

Thanks for the questions. A lot of our users have complained over the years of really poor performance, and all of this can be traced back to how code generators utilize //go:generate. Moving away from this model into a singular config file (or one config file per service if you're in a monorepo) solved this problem. Because of that, going backwards would defeat one of the major purposes for the introduction of the packages feature in v2.

It's worth noting that you can still use //go:generate to invoke mockery, but you can't currently specify precise interfaces to target from the CLI. The most you can do is something like //go:generate mockery --config ./.mockery.yml.

Hardcoding package names is bad practice. Codebases grow and evolve, and having to constantly update configuration files along with package changes is undesirable.

I'm quite surprised that you find this to be a concern. I've used mockery in large projects as well and I don't find the churn in .mockery.yml to be that dramatic. Even so, you can structure your configuration in a way that doesn't require specifying every interface. For example you can do something like this (which is actually all you really need, unless you want lots of customization):

all: true
recursive: true
packages:
  github.com/org/repo:

This will simply generate mocks for all interfaces recursively for all packages under the root. It will also generate only a single mocks_test.go file for each package. I am betting that you currently have a single file for each interface being mocked, as that is how most code generators worked (and it's how mockery worked in v1 and v2).

My main proposition to you is that mockery v3 will reduce the amount of work your developers have to undertake because of its capability to auto-discover interfaces in this manner. Its ability to write all mocks for a package into a single file will likely clean up your repo as well.

[spirin]

I hear you — that’s unfortunate news.

We don’t need mocks for all interfaces, and manually specifying packages is not a viable option for us.
We also don’t need to compile all mocks into a single file — that leads to constant merge conflicts.

For now, it seems we’ll have to stick with v2. Hopefully, a more distributed-style solution will emerge that works with go:generate.

For example, a command that, based on parameters in the v2 style, generates a temporary config for a specific interface and then runs the main generator with that config.

[LandonTClipp]

I am definitely open to supporting this in the future if it turns out to be commonly requested. I have to weigh the burden of additional maintenance with what users want. For what it's worth, I'm supporting v2 until 2029 so there will be lots of time to come up with a solution (either from your side or mine).

[spirin]

We've tried different configuration options and eventually settled on this template for old services:

all: true
recursive: true
structname: "{{.Mock}}{{.InterfaceName | firstUpper}}"
filename: mock_{{ .InterfaceName | snakecase | lower }}.go
force-file-write: true
template-data:
  unroll-variadic: true 

packages:
  github.com/some-package:

The result is about the same as before, only without go:generate and on the new version.
Maybe it will be useful to someone.