I am not sure if I follow, why would the unignore being the last makes the glob empty?

I was primarily trying to make the change as small as possible within the existing code. Basically for the globalIgnore case...they are equivalent because if it's unignored, then we don't return globs anyways (i.e. the code carries on). It's by definition impossible to be ignored if the globs match as an unignore.

However, I put up a different take I was thinking about that might be better for the per config case. It might be a little more/less of a brain twister. In the new code, we disconnect the pushing of the config from the pushing of the globs. This new case will then return the unignored globs, but not push the config, which may be more useful for debugging or more clear as shown below (i.e. it does match technically)

Old approach:

Revised approach:

In terms of why cueing on the last item works. Globs are evaluated in order, so you can walk through the list of globs for a config. Given **/foo/special.js:
**/*.js. - File is ignored
!**/special.js. - File is unignored (this negates the previous matches)
**/foo/special.js - File is reignored (this negates the negation, or rather readds it from an unmatched state)

So using that logic, since we walk them in order, if the last matching glob is a positive matcher, than effectively all the other globs don't matter, it matches; the result is the file is ignored. If the last matching glob is an unignore (!), than no matter what the order of the things preceding it is, the final result is that it undoes all the ignores and it doesn't match.

But won't there be the case of mixing of different types?

**/*.js
**/foo/*.js
!**/foo/special/*
**/foo/special/**/*.ts
...

I think we might better run a proper test for each glob with their priority?

The globs we are cuing on have already been matched on line 69. So it's impossible to generate a file name that would cause both of these to match since they have mutually exclusive file extensions:
**/foo/*.js
**/foo/special/**/*.ts

Don't get me wrong, this is still not totally accurate with how ESLint actually works. For instance:

The pattern directory/** ignores the entire directory and its contents, so traversal will skip over the directory completely and you cannot unignore anything inside.

So it's very easy to make something that minimatch in the inspector will match but isn't in line with how ESLint works. But the issue is that we're fundamentally reimplementing the logic inside ESLint, so it will never be perfectly in sync and accurate. However, this change makes it more accurate.

@antfu I think we're on slightly different schedules, but let me know if you want to hop on discord or something and take this off async delay!

I am still not sure if I understand the logic here. Could we have some test cases to at least guard the behavior here?

Done! There was no testing in this package previously so I also had to setup and configure all that, so it's expanded the PR a bit. I used Mocha and followed the general style from other ESLint packages so that hopefully it's familiar/consistent