Open conartist6 opened 5 years ago
I think the thing to do is to parse the glob, then potentially warn and fall back. I'll work on a PR.
Hmm, it's more interesting than that I guess. Here's what watchman actually supports for globbing: https://github.com/facebook/watchman/blob/061e6abd75449256e00cd8880b94d030f3360ee4/tests/wildmatch_test.json
I opened a PR for option 2 since it's the simplest correct behavior.
Also it seems like wildglob supports [!...]
and [^...]
for negated character classes where ...
is characters which should not be part of the class. It seems that micromatch only supports [^...]
.
Fortunately it should be possible to use the parser to translate from [!...]
to [^...]
er, actually I guess the translation would be from [!...]
to [\!...]
I'm also going to follow up with watchman and see if it would be possible for them to gain more support by using fnmatch
Oh, and it looks like sane can gain at least braces support for watchman using micromatch.braces(glob, { expand: true })
Unfortunately I none of the glob parsers I've found (save glob-parse, which is hardly well supported) give me the flexibility to identify the source text of POSIX brackets glob segments, so for the moment I think it's OK to let that smaller issue persist.
If a version of watchman is in use that has the
wildmatch
capability, sane will delegate checking of glob patterns to watchman. Unfortunately watchman's globbing is not micromatch compatible. It seemingly just supports**
and*
.It seems like this issue could be fixed several ways:
*.{css,scss}
to*.css
and*.scss
. Where it is unreasonable to do this, either fall back or warn the user.