You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I currently do not allow this because mockery attempts to automatically determine if the output mock file is in the same package as the originating interface. I initially attempted to allow multiple packages in the output mock but was running into issues with this "is inpackage" determination, so I decided to defer this until later.
This is not theoretically impossible, it just requires extracting this logic out of the template generator constructor and into the logic that populates imports for each method.
The text was updated successfully, but these errors were encountered:
I've decided that we probably don't want to support this without changes to the config schema. The main issue arises when mockery needs to determine which package-level config to use for the top-level attributes such as pkgname, dir, filename etc. Which package-level config should it use? Well, we could enforce that for all of these top-level configs, mockery asserts the values are the same across all packages. This seems gross and brittle.
Instead, I think we should introduce an alternate config that looks something like:
This model is more explicit on how config merging is done and it's clearer where the top-level attributes come from.
It makes sense for us to support this in parallel to the typical packages: config scheme because most people utilize the templating system to dynamically specify where mock files should live, e.g. dir: "{{ .InterfaceDir }}". The files: schema requires you to explicitly specify where the mock lives.
I currently do not allow this because mockery attempts to automatically determine if the output mock file is in the same package as the originating interface. I initially attempted to allow multiple packages in the output mock but was running into issues with this "is inpackage" determination, so I decided to defer this until later.
This is not theoretically impossible, it just requires extracting this logic out of the template generator constructor and into the logic that populates imports for each method.
The text was updated successfully, but these errors were encountered: