Generating mocks for another repo.

[thespags]

Hi, I'm curious about generating mocks for a 3rd party library.
Temporal isn't updating their mocks folder, https://github.com/temporalio/sdk-go/tree/master/mocks, in fact they rejected my MR request. temporalio/sdk-go#2137

If I'm reading mockery's config correctly, you need a go file at the root to recursively walk the entire tree.
Am I missing a way to generate another repo without doing my own fork?

[LandonTClipp]

Unfortunately yes, this is a limitation that you need a Go file at the root if you want to recursively walk the tree. This comes from the Go language itself and how it handles downloading external repos. Have you actually tried this though? It's worth revisiting if the situation has changed.

[thespags]

Neat! Some more questions, although they may be edge cases not worth mockery having to handle....

What if I wanted to do only specific interfaces?

  go.temporal.io/sdk:
    config:
      recursive: true
      pkgname: temporalmocks
      dir: mocks/{{.SrcPackagePath}}
    interfaces:
      Client:
      Worker:

I get back, can't find the client...

Also, if I can't import multiple packages into the same mock package with recursive, but I can do

  go.temporal.io/sdk/client:
    config:
      pkgname: temporalmocks
      dir: "mocks/temporal_mocks"
    interfaces:
      Client:
  go.temporal.io/sdk/converter:
    config:
      pkgname: temporalmocks
      dir: "mocks/temporal_mocks"
    interfaces:
      EncodedValue:

If I had to sum up...
"I want to mock only these things from this library into the same package for discoverability"

Instead of looking at client_mocks, worker_mocks, interceptor_mocks, I can look at temporal_mocks.
And instead of writing one rule per package for what I need, I can write one rule for the repo.

I understand if this isn't worth solving for, as I do have a workable solution.

[LandonTClipp]

recursive works by mockery downloading the module and then it walks the directory to find all subdirectories that have a go file or are submodules. It then injects the discovered package names into the in-memory config map and copies everything from the base package into the new subpackage. This is why it says it can't find Client because not every package will have an interface named this. This "can't find interface" behavior could be turned off, we'd just need a parameter for it. A way around this is to use include-interface-regex to match interfaces this way. If you then need to further customize config for a specific interface, you just have to write out the package and interface sections for that interface. Mockery understands how to do the config merging even in this case.

Also, if I can't import multiple packages into the same mock package with recursive, but I can do

The limitation is that one output file (a "collection") can only contain interfaces from the same package. The output package does not have this limitation, you can put them in the same directory, just not the same file. This is not recommended though because you can get into naming collisions.

[thespags]

Thanks for all the info.

One last one, hopefully. I wanted to play around with exclude-subpkg-regex: and I was trying

      exclude-subpkg-regex:
        - "internal"

but mockery still seems to be writing things from the internal package.

[LandonTClipp]

I'm not sure. Try turning on debug logs and filtering the messages on the package path. Mockery relies on something like this: https://go.dev/play/p/uZkhSyiN6th

[thespags]

Thanks. It's working as designed. My mistake was reading the output.