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

Exclude specific subfolder from --all #395

Closed
lordzsolt opened this issue Jul 8, 2021 · 16 comments · Fixed by #596
Closed

Exclude specific subfolder from --all #395

lordzsolt opened this issue Jul 8, 2021 · 16 comments · Fixed by #596

Comments

@lordzsolt
Copy link

lordzsolt commented Jul 8, 2021

Mostly a followup to #255, with the introduction of go modules, dependencies are in the vendor subfolder.

With the command mockery --all, mocks will be generated for all interfaces of third party dependencies.

It would be great to have some way of excluding this folders (and potentially other ones).

Is there a way to do this already?

@remidebette
Copy link

Hi,

I agree on the need for this.
Currently a feature --all which is the first presented in the readme file is actually unusable with a vendor folder

@vasconcelosvcd

This comment was marked as spam.

2 similar comments
@trim21

This comment was marked as spam.

@AntonioYuen

This comment was marked as spam.

@alec-w
Copy link

alec-w commented Apr 21, 2022

I'd also find this feature useful.

Taking a look at the code it looks like the behaviour change would be within

func (w *Walker) doWalk(ctx context.Context, p *Parser, dir string, visitor WalkerVisitor) (generated bool) {

I'd have a stab at a PR on this (although whether the v3 overhaul might make this undesired is to be seen), but an open question is - should the exclude be just for top level directories or any subdirectory matching a given pattern (and if the latter, how to make sure root1/foo is included but root2/foo is excluded?)?

@LandonTClipp
Copy link
Collaborator

LandonTClipp commented Apr 21, 2022

Thanks for the engagement everyone. Two quick thoughts I have, please refrain from commenting +1, we have thumbs up reactions which serve the same purpose! Second, I'm thinking there are two ways of doing this:

  1. Have some config that skips certain subpaths (probably the most intuitive)
  2. Have a magic hidden file, like .mockery_skip that if the walker finds, will skip the entire subdirectory.

I think 2 is a bit more portable and easier to code for. Which of these would people prefer? Or maybe there is a secret third option I'm missing.

@alec-w
Copy link

alec-w commented Apr 21, 2022

I'd vote for option 2, I hadn't even thought of that alternative!

Imagining code to support this would be simpler which is a big plus. Although config might be more intuitive, the exact way in which the subpaths have to be specified would require reading docs more carefully, whereas the .mockery_skip usage should be obvious to anyone familiar with things like .gitignore.

@alec-w
Copy link

alec-w commented Apr 26, 2022

PR opened for implementing .mockery_skip. First time contributing something more than a trivial doc change to OS so any guidance on improving the PR description / approach very welcome 🙂

@subtle-byte
Copy link

In my mocks generator it is possible to exclude specific subfolder) https://github.com/subtle-byte/mockigo

@hedhyw
Copy link

hedhyw commented Jun 6, 2022

Option 1:
There are too many configs these days, but this option is more extensible 👍.

Option 2:

  1. I am not sure about the .mockery_skip method, because if we place it in the /vendor directory, then it will be deleted after each go mod vendor call.
  2. This option may not work with generated files if the generator deletes the folder.
  3. It is hard to make new functionality.

    software entities should be open for extension.

I see that there is already a PR for this #458.

Option 3:
I would be happy to have a flag that provides a regular expression for excluding folders 😥.

P.S.: "Add ability to skip vendor folder when using --all flag": #377

@mohammadne
Copy link

is there any update on this topic?

@bdandy
Copy link

bdandy commented Sep 28, 2022

Probably skipping vendor should be as default behavior

@lordzsolt
Copy link
Author

lordzsolt commented Nov 7, 2022

I feel like the .mockery_skip is a horrible approach, the way it's described here. I don't want to create 10+ files for each subfolder.

Why not just have a .mockery.toml (or yml or whatever) config file, where you can add the parameters you want, and you can also have included and excluded flags with a regex, which is an array of paths to include or exclude?

Considering it's not a huge sausage shell command that you have to write out with all the parameters, it's nice and easy to understand and maintain.

There's no need to reinvent the wheel, that's how every other tool deals with files does, so it's intuitive for people as well.

@lordzsolt
Copy link
Author

As for anyone that got to this thread, and has the same problem, I managed to solve it by removing the --all flag, and find the files myself with go list.

go list -f '{{.Dir}}' ./... | xargs -n1 mockery --all --case underscore --inpackage --disable-version-string --with-expecter --note "NOTE: run 'make update-mocks' to update this file and generate new ones." --dir

You can also use grep to exclude certain stuff, if you would like.

go list -f '{{.Dir}}' ./... | grep -v "stuff-to-exclude" | xargs -n1 $(shell pwd)/bin/mockery --all --case underscore --inpackage --disable-version-string --with-expecter --note "NOTE: run 'make update-mocks' to update this file and generate new ones." --dir

@LandonTClipp
Copy link
Collaborator

Circling back on this, I am in favor of adding a configuration parameter to exclude directories. Please do submit a PR, if it's good then we can get it merged!

@amirbenun
Copy link
Contributor

Hey @LandonTClipp,
I opened a PR with the changes you suggested #596.
Hopefully we can push it forward.

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

Successfully merging a pull request may close this issue.