Copy an entire directory except one sub-directory

[brunoimbrizi]

Is it possible to copy an entire directory except one sub-directory?
Please consider the following scenario:

INPUT:

mydir/
├─ first
│  ├─ keep.js
│  ├─ keep.jpg
│  └─ keep.webm
├─ second
│  ├─ sub-second
│  │  └─ keep.webm
│  ├─ keep.jpg
│  └─ keep.png
└─ not-this-one
   ├─ skip.jpg
   └─ skip.png

EXPECTED:

output/
├─ first
│  ├─ keep.js
│  ├─ keep.jpg
│  └─ keep.webm
└─ second
   ├─ sub-second
   │  └─ keep.webm
   ├─ keep.jpg
   └─ keep.png

This might be a fast-glob question, but I think the issue is not so much on the src pattern and more on the dest options available.
Here's a few attempts. Assume vite.config.js plugins:

1. Default usage

viteStaticCopy({ targets: [ src: 'mydir', dest: 'output' ] });
// outputs an identical copy of mydir inside /output

2. From fast-glob How to exclude directory from reading?

viteStaticCopy({ targets: [ src: [ 'mydir/**', '!mydir/not-this-one/**' ], dest: 'output' ] });
// correctly skips /not-this-one, but doesn't preserve the original folder structure
// outputs /sub-second as a sibling of /second

3. Same as 2. but without /**

viteStaticCopy({ targets: [ src: [ 'mydir', '!mydir/not-this-one' ], dest: 'output' ] });
// outputs an identical copy of mydir inside /output, including /not-this-one

4. Passing flatten: false

viteStaticCopy({ targets: [ src: [ 'mydir/**', '!mydir/not-this-one/**' ], dest: 'output' ], flatten: false});
// correctly skips /not-this-one and keeps the folder structure
// but creates /output in the root directory, in my case C:/output (Windows)

It seems like 4. is almost what I'm after, but dest is doing something unexpected when flatten: false is used.
To reiterate the question: what would be the correct approach to copy an entire directory, keeping its folder structure, including all file types, at the same as excluding one sub-directory?

[brunoimbrizi]

Follow up: after investigating a bit more I realised the issue wasn't so much about the exception in the glob.
I created an issue #46 to clarify and also opened a PR #47 with a suggested solution.