-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Watchman does not understand micromatch globs #145
Comments
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 |
Fortunately it should be possible to use the parser to translate from |
er, actually I guess the translation would be from |
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 |
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.The text was updated successfully, but these errors were encountered: