Skip to content
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

arg package name collision within generated mock #798

Open
3 tasks
CoderCoco opened this issue Jul 24, 2024 · 2 comments
Open
3 tasks

arg package name collision within generated mock #798

CoderCoco opened this issue Jul 24, 2024 · 2 comments

Comments

@CoderCoco
Copy link

Description

When generating mocks that references a package named args a collision occurs with the generated mock Run function.

This is generated:

func (_c *mockArgsInterface_isMetricDestination_Call) Run(run func(_a0 args.MetricDestination)) *mockArgsInterface_isMetricDestination_Call {
	_c.Call.Run(func(args mock.Arguments) {
		run(args[0].(args.MetricDestination))
	})
	return _c
}

There is a collision between args.MetricDestination and the local variable args

Mockery Version

2.43.2

Go Version

1.22

Installation Method

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

Steps to Reproduce

  1. Create a package named args that has a type you wish to import.
  2. Create an interface in another package that has a parameter type from that package.
  3. Execute mockery
  4. Test compilation fails

Expected Behavior

I would expect the mock to be generated correctly.

Actual Behavior

A mock is generated but when running tests I get this message: render/mock_args_interface.go:99:21: args.MetricDestination is not a type

@CoderCoco
Copy link
Author

I have a work around by replacing the package causing the issue in the configuration. However, I don't think that this really fits the use case defined by the replace-type option.

@LandonTClipp
Copy link
Collaborator

Sorry, the collision handling logic is long in the tooth and doesn't comprehensively handle cases like this. Unless someone wants to tackle that project, using replace-type is probably the correct approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants