improve and completely rework exclude optimizer

[SuperchupuDev]

shorter and probably faster implementation 🎉 also improves optimization for patterns that end with **

needs some work, this implementation (and the previous one) don't work well with patterns that wrap / in things like *(src/index.ts). see #76 (comment) disabled optimizations in those cases for now

also closes #79 once the above is solved, and makes tests from #80 work :-)

EDIT: REWRITTEN FROM THE GROUND UP with a different approach to avoid the many edge cases it used to have

[pkg-pr-new]

Open in Stackblitz

npm i https://pkg.pr.new/tinyglobby@76

commit: 6d5b0bb

[SuperchupuDev]

while the tests do pass now thanks to the new fdir version fixing excluding symlinks, this implementation doesn't handle patterns that have / inside glob symbols well, for example this test that i haven't pushed:

test('dynamic patterns that include slashes inside parts', async () => {
  const files = await glob({ patterns: ['{.a/a,a}/a.txt'], cwd });
  // files ends up being []
  assert.deepEqual(files.sort(), ['a/a.txt', '.a/a/a.txt']);
});

it's easy to see why it fails but hard to properly fix. other than splitting the parts with picomatch which is easy to do (now done), i'm not sure how to modify the code to properly account for it. there's an option to just replace parts that have / with ** but it should be the last choice as that would just skip optimizations

[benmccann]

Would it help to have tinyglobby expand ['{.a/a,a}/a.txt'] to ['.a/a/a.txt', 'a/a.txt'] as a first step?

[SuperchupuDev]

maybe but i'm not sure if it's optimal

[SuperchupuDev]

globbing update: this PR breaks some use cases of broken parentheses, because for some weird reason globbing unescaped parentheses also matches literal parentheses. i really wish we could get a partial option on picomatch

[SuperchupuDev]

the optimizer was completely rewritten again! the above comment no longer applies. should be ready to go :-) will test some more

[Fuzzyma]

Found a little nitpick :D.

Also a "question" regarding your use of regexes. I learned, that regexes need to be compiled. So creating them via /regex/ on the fly might double up work. If the regexes are likely to be used anyway (and more than once), define them on the module level so the compile step is only done once

[SuperchupuDev]

@Fuzzyma @pralkarz suggestions have been applied in 8872e68, let me know if y'all want me to change anything else 👍