-
Notifications
You must be signed in to change notification settings - Fork 409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--replace-type is not mapping packages correctly #688
Comments
Hi thanks for the report, I'll be looking through this to get a better understanding. |
Hi. I face a similar issue:
Instead of |
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 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 |
Yes. It seems that |
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. |
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. |
@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 😄 |
Hmm I tried some initial fixes but it was more complex than I thought, probably would need to refactor the 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! |
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 fromreplaceType
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
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 theblob
alias, notblockblob
Actual Behavior
DeleteResponse
is incorrectly referenced using theblockblob
alias. See here for an example.The text was updated successfully, but these errors were encountered: