Feature Request: add more template functions

[SirSova]

Description

Right now the list of possible template functions is pretty small. I suggest to use the same set of functions as helm does.
Masterminds/sprig provides general FuncMap that can be used in addition to existing functions.
This approach will also allow to avoid multiple variables for InterfaceName (InterfaceNameCamel / InterfaceNameLowerCamel / InterfaceNameSnake / InterfaceNameLower). It should be done as: {{ .InterfaceName | upper }} or {{ .InterfaceName | snakecase }}

Mockery Version

v2.33.2

Golang Version

v1.20

Installation Method

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

[LandonTClipp]

The multiple variable names for interfaces was just bad planning on my part, I don't have an excuse for that. I'm surprised you think the list of function is "small," I thought we added quite a lot 😅

One of the things we need to do is fix the argument ordering because currently pipelining is sort of broken for the functions we currently have. I think we need a feature flag that fixes the argument ordering, and then add any additional functions to the set of functions enabled with that flag (this way, people are encouraged to use the new function set).

I'm not really sure if we need this mega set of functions that sprig provides. It's certainly enticing but I would like a better argument for attaching ourselves to that project rather than just "more functions = good". The number of variables that support templating in this project is pretty low, and mostly involves path/name manipulation. I think sprig is more useful for large HTML templates (or any text document really). Consequently, I don't see a good argument for adding it. It's a huge dependency for not that much value, IMO.

[SirSova]

I agree that for mockery purposes there is no need for all the functions. What I actually wanted is String functions, because I have a problem converting .PackageName to CamelCase)
Sadly, the sprig doesn't provide a subset of functions, but it uses this dependency for most string functions huandu/xstrings. Right now as I see, mockery uses a less extensive library iancoleman/strcase. We can switch them I guess and add just names => callbacks map for them.

[ehsundar]

We may select a smaller set of functions or implement them in this codebase. Could you please tell us what was your exact problem? What's your package name?

[SirSova]

So basically my plan was to create a general mockname for all structs that I generate with pattern like this:

mockname: "{{ .PackageName | camelcase }}{{ .InterfaceName | camelcase }}"

# expected: PkgNameSomeService
# actual: pkgNameSomeService

For InterfaceName I found that a separate variable (InterfaceNameCamel), but not for the package. As a result, my mocks were not public. And I didn't find the option for uppercasing the 1st character as well.

So I did just:

packages:
    pkgName:
        interfaces:
            SomeService:
                config:
                    mockname: PkgNameSomeService

but I have more than 10+ interfaces with such a config.

Here is the list of functions that I would like to have:
ToLower
ToTitle
ToUpper
ToCamelCase
ToKebab
ToSnakeCase
FirstRuneToLower
FirstRuneToUpper

[LandonTClipp]

I am totally okay with adding those list of functions you mentioned, I think those are definitely useful for folks. Do you want to add a PR? I could probably do it myself but it will take me maybe a couple of weeks.

[SirSova]

Yes, I can do it myself, not a problem.