Reintroduce CLI args; make config file optional

[jamesphillpotts-fr]

We maintain a large golang project with thousands of golang files across hundred of packages and have been using mockery v2 for many years, and it has been great. We recently decided that we should switch to v3 as that is where active development is focusing. We have found that for a large repository, the configuration file approach offers a much poorer developer experience, as even using config snippets that are reused using yaml anchors, we still end up with hundreds of lines worth of configuration yaml, that is far away from the interfaces that it relates to, with no tooling for managing it in a usable way.

When using v2, we managed our mock generation using (a) mockery version fixing in go.mod (meaning all contributors are using the same version), and (b) go:generate annotations such as:

//go:generate go tool mockery --name=Validator --with-expecter --inpackage

//go:generate go tool mockery --name=Client --with-expecter

//go:generate go tool mockery --name=Servicer --with-expecter --inpackage --case underscore

etc.

With this approach IDE integration worked brilliantly, and it was clearly documented next to each interface what mock generation was doing, and CLI users were still able to regenerate using go generate, and we didn't have to worry about version drift between different users that can result

The documentation does note that we could stay on v2 until 2029, but we're keen to move forwards, but it would really be much nicer if you still supported the old approach to mockery invocation, rather than forcing the use of the configuration file.

I appreciate that you want to continue to develop mockery and that you probably had more good reasons to make this change than those that I'm aware of, but I'm hopeful that this feedback is useful and that you might consider how this usage pattern could be supported in the future.

[LandonTClipp]

There's nothing theoretically impossible preventing us from supporting CLI args. We'd have to perform some sort of mapping operation between the provided CLI args and an equivalent yaml file (or rather, just in-memory config map to be more precise). It's awkward to support this because the entire point of removing CLI args was the massive performance gains you get when everything is generated within a single mockery invocation. But I also realize different projects have different requirements, and speed isn't always a concern.

There is a sort of related PR that was submitted that addresses this from a slightly different angle: #1105

As a matter of where I spend my personal time implementing things, I'm not super willing to devote time to this because nearly all of the major open source projects that use mockery v3 are completely happy with the config file approach. I've barely received any complaints to the contrary. BUT... if someone submitted a PR that is able to cleanly map CLI parameters to an equivalent in-memory config map and prove it works, I would certainly give it serious consideration and probably get it merged assuming the implementation is good and it's easily maintainable.

[jamesphillpotts-fr]

#1105 does look like it would get most of the way there 👍

It's a shame there isn't a mechanism for tools like mockery to attach themselves to the go generate mechanism without adding directives into the source code.