common path algorithm calculates parts wrong with `/` inside part

[jxn-30]

Given a nested file structure:

Click me to open file tree

.
├── a
│   ├── e
│   │   ├── h
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── i
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── j
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── n.txt
│   │   ├── o.txt
│   │   └── p.txt
│   ├── f
│   │   ├── h
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── i
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── j
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── n.txt
│   │   ├── o.txt
│   │   └── p.txt
│   ├── g
│   │   ├── h
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── i
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── j
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── n.txt
│   │   ├── o.txt
│   │   └── p.txt
│   ├── q.txt
│   ├── r.txt
│   └── s.txt
├── b
│   ├── e
│   │   ├── h
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── i
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── j
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── n.txt
│   │   ├── o.txt
│   │   └── p.txt
│   ├── f
│   │   ├── h
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── i
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── j
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── n.txt
│   │   ├── o.txt
│   │   └── p.txt
│   ├── g
│   │   ├── h
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── i
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── j
│   │   │   ├── k.txt
│   │   │   ├── l.txt
│   │   │   └── m.txt
│   │   ├── n.txt
│   │   ├── o.txt
│   │   └── p.txt
│   ├── q.txt
│   ├── r.txt
│   └── s.txt

When running the glob ./{a/e,b/f}/{n,o,k}.txt, I expect to match the files ./a/e/n.txt, ./a/e/o.txt, ./b/f/n.txt, ./b/f/o.txt. tinyglobby however does not match any files.
When running the glob ./{a/e,b/f,**/*}/{n,o,k}.txt, I expect to match a total of 30 files. tinyglobby however does not match any files.

I've created a minimal reproduction example in https://github.com/jxn-30/tinyglobby-brace-expansion that shows how tinyglobby differs from fast-glob/globby at this point.
Glob tester also shows how minimatch produces the same result as fast-glob/globby.

[SuperchupuDev]

interesting 🤔, will debug and try to fix

[SuperchupuDev]

the fix is simple, however there is a bug (currently only present on main) that needs to be fixed first. thanks for reporting!

[SuperchupuDev]

FYI: while this is getting fixed in the next release, there are some perf optimizations that will benefit every possible pattern, except the ones that have / inside a part. So it'll get fixed but I don't recommend you to use those patterns anyways unless we figure out a optimization for this use case (or picomatch ports the partial option from minimatch which would easily solve this)

[jxn-30]

Thanks! 👍

I unfortunately don't see a way not to use / in parts atm.
I use glob import in vite with dynamic globs, determined at build time. As I can only pass the dynamically genrated glob via env, I cannot pass an array of globs, which would eliminate the need to use / in parts.