Skip to content
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

Behavior of parenthesis in match #107

Open
Superskyyy opened this issue May 3, 2022 · 6 comments
Open

Behavior of parenthesis in match #107

Superskyyy opened this issue May 3, 2022 · 6 comments

Comments

@Superskyyy
Copy link

Hi community,

I just encountered the following

pm.isMatch("CON.md", "!(**/*.md)",{dot:true}) ? "match" : "no match" - > returns match

pm.isMatch("CON.md", "!(*.md)",{dot:true}) ? "match" : "no match" - > returns no match

without negation
pm.isMatch("CON.md", "**/*.md",{dot:true}) ? "match" : "no match" - > returns match
pm.isMatch("CON.md", "(**/*.md)",{dot:true}) ? "match" : "no match" - > returns no match

Why is the parenthesis matter? I appreciate some help.

@Superskyyy
Copy link
Author

I realize this maybe similar to #104, can someone please confirm?

@jonschlinkert
Copy link
Member

This is correct. I believe parentheses are matched as literal characters when no preceded by an extglob charcter (!?@*+).

@Superskyyy
Copy link
Author

Superskyyy commented May 3, 2022

This is correct. I believe parentheses are matched as literal characters when no preceded by an extglob charcter (!?@*+).

Thank you for the reply @jonschlinkert, but please take a look at the first one, even with negation, the CON.md is still matched, returning the same result when it is not with negation. Is there a correct way to do it?

I'm trying to use Picomatch to ignore files before processing other files in a repository (that is do not know what to include, we can only exclude known ones), but as you can see here in the screenshot, it is not recognizing the files at root level when I use **/*.md, is there any way that I can fix this? I've been scratching my head for hours...

image

I can confirm that problems only occur whenever a double asterisk appears at first position in an expression, so I can only avoid leading **, plus using * to help catch the missing files.

@jonschlinkert
Copy link
Member

It might be a bug that !(**/*.md) is matching CON.md. It looks like it ought to be considered a bug, unless I'm forgetting some rule in bash glob. (fwiw, negation extglobs are difficult to get right. But negation extglobs with nested globstars --double *-- are very difficult to get right (this is mainly due to the limitation of JavaScript's regex engine and the absence of useful features like atomic groups. Picomatch will eventually be updated to use lookbehinds, which will help with this, but the community and browsers are not quite ready for those yet. We can't rely on transpilers to properly re-create lookbehinds in a backward compatible way).

Any help from contributors would be appreciated, or I can look into this as soon as I get a chance.

Suggestions

In the meantime, a couple of suggestions for how you're doing matching:

If you're doing to use the same pattern multiple times, use the main function returned by picomatch to create a matcher function instead of calling pm.isMatch() each time.

const isMatch = pm('!(**/*.md...)', { dot: true });
// then
isMatch('abc.md');
isMatch('foo/abc.md');

Instead of using a negative extglob with multiple conditions (!(**/*.md|....)), either pass an array of globs or try using braces, or a combination:

['!**/*.md', '!**/*.txt', ...]
// or 
['!**/*.{md,txt}', ...]
// or
'!**/*.{md,txt,gitignore,licenserc.yaml,codestyle.xml}'

@jonschlinkert
Copy link
Member

also, thank you for creating the issue and for helping to figure this out!

@Superskyyy
Copy link
Author

also, thank you for creating the issue and for helping to figure this out!

I should thank you, without Picomatch our open-source projects will be wasting a lot of CI time at non-functional file changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants