Regression in the new version (3.2.3) when using the caseSensitiveMatch option is disabled

[ifitzsimmons]

Environment

• OS Version: OSX
• Node.js Version: v13.11.0

Actual behavior

Throws undefined error -- no info.

Expected behavior

Expected results, works when I revert to 3.2.2

Steps to reproduce

Didn't work with sync search either.

Code sample

const dirsFound: FastGlob[] = await fg(`${dirPath}/**/${searchTerm}*`, {
      deep: 2,
      onlyDirectories: true,
      objectMode: true,
      caseSensitiveMatch: false
    });

[mrmlnc]

Please, provide the full pattern without placeholders and the text of the error.

[zachleat]

There’s something here I think—I’m seeing very new regressions in my projects too. Works fine when I explicitly declare fast-glob to 3.2.2 instead of ^3.2.2 (which uses 3.2.3)

[ifitzsimmons]

No text for the error.

dirPath = ~/Library/ApplicationSupport/Electron
searchTerm = Apple

Might be because ApplicationSupportis a link to Application Support, but the later used to work and now does not. Worked fine before I pulled in the new release and works fine now that I've reverted to 3.2.2

[zachleat]

      fastglob("./src/static/", {
        caseSensitiveMatch: false,
        dot: true
      })

gave me

Problem writing Eleventy templates:
Expected a non-empty string
`TypeError` was thrown:
(error stack): TypeError: Expected a non-empty string
    at Function.picomatch.makeRe (/Users/zachleat/Code/a-project/node_modules/picomatch/lib/picomatch.js:274:11)
    at Function.micromatch.makeRe (/Users/zachleat/Code/a-project/node_modules/micromatch/index.js:387:44)
    at Object.makeRe (/Users/zachleat/Code/a-project/node_modules/fast-glob/out/utils/pattern.js:114:23)
    at /Users/zachleat/Code/a-project/node_modules/fast-glob/out/providers/matchers/matcher.js:42:42
    at Array.map (<anonymous>)
    at PartialMatcher._getPatternSegments (/Users/zachleat/Code/a-project/node_modules/fast-glob/out/providers/matchers/matcher.js:31:22)
    at PartialMatcher._fillStorage (/Users/zachleat/Code/a-project/node_modules/fast-glob/out/providers/matchers/matcher.js:19:35)
    at new Matcher (/Users/zachleat/Code/a-project/node_modules/fast-glob/out/providers/matchers/matcher.js:10:14)
    at new PartialMatcher (/Users/zachleat/Code/a-project/node_modules/fast-glob/out/providers/matchers/partial.js:4:1)
    at DeepFilter._getMatcher (/Users/zachleat/Code/a-project/node_modules/fast-glob/out/providers/filters/deep.js:16:16)
    at DeepFilter.getFilter (/Users/zachleat/Code/a-project/node_modules/fast-glob/out/providers/filters/deep.js:11:30)
    at ProviderAsync._getReaderOptions (/Users/zachleat/Code/a-project/node_modules/fast-glob/out/providers/provider.js:25:41)
    at ProviderAsync.read (/Users/zachleat/Code/a-project/node_modules/fast-glob/out/providers/async.js:12:30)
    at Array.map (<anonymous>)
    at getWorks (/Users/zachleat/Code/a-project/node_modules/fast-glob/out/index.js:58:18)
    at FastGlob (/Users/zachleat/Code/a-project/node_modules/fast-glob/out/index.js:10:19)

[mrmlnc]

Thanks for the stacktrace I will look at it morning (UTC +3, Russia, Moscow). It's strange that no one test has caught the problem.

I think the problem is here. We consider an empty string as a dynamic pattern and try to create a regular expression for it.

https://github.com/mrmlnc/fast-glob/blob/98e566c245fd677426294068e8d3de4ffb95ebc4/src/utils/pattern.ts#L28#L33

[zachleat]

Thanks @mrmlnc! 👍🏻

[mrmlnc]

Shipped with 3.2.4.