generated mock incorrectly imports package ending in .go

[scags9876]

With the following package in internal/mockerytest/mockerytest.go

package mockery_issue

import (
	"github.com/nats-io/stan.go"
)

type StreamClient interface {
	GetSubscriptionOption() stan.SubscriptionOption
}

Generating a mock for this interface does not compile. In the code below, import stan "github.com/nats-io/" should be import stan "github.com/nats-io/stan.go"

$ mockery -dir internal/mockerytest -print -all
// Code generated by mockery v1.0.0. DO NOT EDIT.

package mocks

import mock "github.com/stretchr/testify/mock"

import stan "github.com/nats-io/"

// StreamClient is an autogenerated mock type for the StreamClient type
type StreamClient struct {
        mock.Mock
}

// GetSubscriptionOption provides a mock function with given fields:
func (_m *StreamClient) GetSubscriptionOption() stan.SubscriptionOption {
        ret := _m.Called()

        var r0 stan.SubscriptionOption
        if rf, ok := ret.Get(0).(func() stan.SubscriptionOption); ok {
                r0 = rf()
        } else {
                if ret.Get(0) != nil {
                        r0 = ret.Get(0).(stan.SubscriptionOption)
                }
        }

        return r0
}

[LandonTClipp]

That package is named very oddly. I guess this is an edge case we probably want to fix. Mind sending in a PR?

[eaardal]

Hi we also ran into this issue. We're using the NATS message queue and they recently renamed their repos to https://github.com/nats-io/nats.go and https://github.com/nats-io/stan.go. Now when we run mockery, it adds the import import nats "github.com/nats-io/" which fails to compile because the import should really be import nats "github.com/nats-io/nats.go".

Besides fixing the bug, an -exclude option would be nice, as it could allow me to exclude this specific problematic package from being mocked in this situation. I usually run mockery with mockery -all -keeptree -dir src. The current workaround for this as far as I can see is to instead mock each package explicitly except the problematic one, where as an -exclude option would perhaps allow me to keep the sexy one-liner.

Thanks for an otherwise awesome tool ❤️

[LandonTClipp]

I think an exclude option would be fine. I'm noticing a general trend of people needing quite complex/varied configuration. In v2.0.0 I will be introducing cobra/viper which will allow much better management of config. Might be good to keep this on hold until I get 2.0.0 released.