--replace-type is not mapping packages correctly

[rkoehl05]

Description

I am trying to mock an interface that requires multiple --replace-type inputs. The target type aliases for these types reside in separate packages but the source internal types are all in the same package. This causes the generate logic to choose the wrong alias when building the mock.

The issue seems to be caused by addPackageImportWithName only looking at the the package portion of the from replaceType here. It should probably scan all the replace type inputs first to see if there is an explicit type-level mapping and then a follow up scan for package-level mappings.

Mockery Version

2.30.1, 2.32.3

Golang Version

1.20

Installation Method

• Binary Distribution
• Docker
• brew
• go install
• Other: [specify]

Steps to Reproduce

I set up a reproducer repo here. You can run go generate. in it to produce the broken mock.

Expected Behavior

The DeleteResponse type should use the blob alias, not blockblob

Actual Behavior

DeleteResponse is incorrectly referenced using the blockblob alias. See here for an example.

[LandonTClipp]

Hi thanks for the report, I'll be looking through this to get a better understanding.

[vitaly-eureka-security]

Hi. I face a similar issue:

packages:
    interfaces:
      IBlockBlobClient:
        config:
          replace-type:
            - 'github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/internal/generated.BlockBlobClientCommitBlockListResponse=blockblob:github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/blockblob.UploadStreamResponse'
            - 'github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/internal/generated.BlobClientDeleteResponse=blob:github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/blob.DeleteResponse'

Instead of blob.DeleteResponse the generated mock contains blockblob.DeleteResponse

[LandonTClipp]

It seems the issue here is that it's not looking at the entire path of the replacement, just the path itself. It looks only at github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/internal/generated and not the name of the struct, so it's selecting the first one it comes across when it should be selecting the second? So instead we might need something like

if path == from.pkg && name == from.name {

in the linked piece of code. Let me know if you think that's the solution, but that's what I'm gathering

[vitaly-eureka-security]

Yes. It seems that addPackageImportWithName should consider the original type name and not just the original package when deciding what replacement rule to apply.

[rkoehl05]

That is what I was considering as well but it wouldn't handle the case where your replace-type is just a package to package mapping.

I was thinking we could do two passes where the first attempt will try to map with pkg & name. The second pass would just use the pkg as long as name is not set.

[LandonTClipp]

I think you're right we'll have to do two passes to get the most specific type replacement possible. I think this could have been resolved if the parameter itself was a mapping instead of a list of strings. If you want to implement the two pass suggestion I'll accept it, but I do think we need a better way to model this.

Edit: on second thought, you don't need two passes. You just have to keep track of specificity and simply select the most specific entry you found through the loop.

[LandonTClipp]

@RangelReale since you were the one who made this feature, I'd give you first dibs if you have the time/energy to do this? No worries at all if you can't, just thought I'd ask 😄

[RangelReale]

Hmm I tried some initial fixes but it was more complex than I thought, probably would need to refactor the addPackageImportWithName to know the object name, but in reality it doesn't need it.

I'm a little busy this week, won't be able to focus too much on it, if you have a solution in mind and want to implement it, go ahead!