Consider adding an option so copy() with no source will not throw.

[binduwavell]

TL;DR; I have a use case in a yeoman generator where the templates I copy are controlled by someone else. And in some instances they ask me to copy a glob that resolves to absolutely nothing. mem-fs-editor.copy() throws in this case. I would like for it to succeed. Would you accept a PR that addresses this in a backward compatible way?

---

I have created code to perform mvn archetype:generate. I provide the manifest xml file and the resource folder and the code goes through the FileSets and Modules defined in the manifest and does what mvn archetype:generate would have done based on the instructions in the manifest.

I use this to scaffold out projects using a few different source archetypes. These archetypes are defined by other people. They are valid maven archetypes. However, one of them has a source glob that ends up not copying anything. Since I embed the exploded archetype in a templates folder in my generator, technically I could resolve this issue by re-writing the manifest rule that is useless. However, I'd prefer to have my code work with unmodified archetypes.

As I said, there are a few cases where the FileSet provides a source glob that ends up returning zero files. Maven handles this by simply not copying anything. This seams reasonable to me.

Unfortunately mem-fs-editor throws in this situation. I can catch this exception, detect if it's failing because nothing was copied and rethrow otherwise.

I'm not a fan of this because right now I would have to rely on mem-fs-editor not changing the text of the exception message in my code. I could write a test for this and update my code if that test failed, but why do that when I could enhance mem-fs-editor to support my use case?

My preference would be to simply provide an option to mem-fs-editor.copy() to indicate that an empty copy is acceptable. My second preference would be for the error that is thrown to be strongly typed rather than having to rely on a string match on the exception string.

Would you accept a PR for either of these approaches to extending mem-fs-editor.copy() for my use case?

[huerlisi]

We are having a similar case where we're providing multiple templates sources for a yeoman generator and a single writing task. Some templates do not have files in some of the directory we copy.

The issue triggered when upgrading yeoman-generator from 0.22.6 to 1.1.1, so I guess this is related to some updated dependency on mem-fs-editor.

My preferred way would also be to have an option I can use to signal the copy process that it's okay if the source is empty.