fix: add more general support for negated exclude rules

[bcoe]

@davewasmer how does this look? very much appreciate the failing tests 👍

[coveralls]

Coverage increased (+0.02%) to 89.07% when pulling 5e838f3 on add-failing-test-negated-exclude into 776d2a3 on master.

[davewasmer]

Seems good! I think this addresses the issues I raised.

One quick question - this logic seems somewhat complex (lots of double negatives), and it seems like the micromatch library supports all this logic directly via negated patterns. Why not just have a single array of include glob patterns, and if you want to exclude files, you use a negated glob? Then we could remove all this logic and just pass that array into micromatch. Is there a use case I'm missing here perhaps?

[JaKXz]

@davewasmer @bcoe I tried taking a different crack at this briefly over the weekend but unfortunately to support all the use cases we want, I ended up with something similarly complex...

I am ok with merging this, but I too am not a fan TBPH.

[bcoe]

@davewasmer I can't quite figure out how to support this elegantly with the micromatch.all functionality -- unless I'm missing something.

The problem is that if you have an include pattern like foo/**, and a negated match like !foo/bar.js, if you have the file foo/bar.js, .any returns true because the rule matches foo/** (even though it fails !foo/bar.js) -- tldr; I couldn't off the top of my head figure out an approach that works elegantly, without building a few different lists of globs that we need to check in an appropriate order.

[bcoe]

@davewasmer might be worth having an extra set of eyes on the micromatch API, to see if anything jumps out at you.

[davewasmer]

I think if you don't use micromatch.any, but instead use the default functionality, it might work:

> mm('foo/bar.js', [ 'foo/**', '!foo/**' ])
[]

[bcoe]

@davewasmer want to submit a patch to this branch 😄 just added you to the project.

[davewasmer]

Nothing like trying to implement it to help you find the flaws.

The critical shortcoming of the micromatch API is that if a filepath matches any negation, it's excluded no matter what. This means that it's impossible to do an "exclude everything except" type of pattern:

> mm('node_modules/foo.js', [ '!node_modules/**', 'node_modules/foo.js' ])
[]

Which is actually the exact use case that led me to find this issue in the first place.

Nevermind then 😉

[bcoe]

@davewasmer sounds like we need to stick with my wonky logic for now?