Bug fix for #96 (.not returning incorrect results on windows)

[doowb]

Bug Fix

• All existing unit tests are still passing (if applicable)
• Add new passing unit tests to cover the code introduced by your pr
• Update the readme (see readme advice)
• Update or add any necessary API documentation
• Add your info to the contributors array in package.json!

Description

Currently, the matches returned from micromatch inside the .not method are removed from the list array (which is the original list of files passed into micromatch.not.

This PR uses utils.unixify on the list array to ensure that the original files are unixified (if specified in the options) so when "diffing" the correct file paths will be remove and returned.

Updates made

• update .not method in the test support matcher
• unixify the list of files passed into micromatch.not
• closes basename: true and unixify: true breaks .not() #96

[jonschlinkert]

@doowb thanks!

The changes look good, but ideally we should try to find a way to not unixify twice, since I believe that's already done for list (

micromatch/index.js

Line 350 in 0fd6207

var matches = utils.diff(list, micromatch(list, patterns, opts));

), everywhere but the first argument passed to diff()

edit: hmm what if we add a .unified boolean to the array. we can make it non-enumerable if necessary, but we can check that before unixifying in the .unixify utility to see if it's already done nvm, unifixy takes a string, not an array. But we could still do something similar

[doowb]

everywhere but the first argument passed to diff()

That's what's causing the issue, because the original paths in the first argument are not unixified, but the paths that are returned are.

But we could still do something similar

Could the unixify utility function keep a cache of file paths so it only unixifies it once? I think you had tried that out for speed improvements before, but I don't think unixify was used enough to see a benefit.

[jonschlinkert]

That's what's causing the issue, because the original paths in the first argument are not unixified, but the paths that are returned are.

right. that's what I meant.

Could the unixify utility function keep a cache of file paths

I wouldn't do that, since we'd then need to implement an lru cache or something that would prevent memory leaks. let's just merge this since it fixes the issue, and I can take a look at optimizing after. thx