-
-
Notifications
You must be signed in to change notification settings - Fork 24
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
fix: match glob logic for unignore ignores #115
base: main
Are you sure you want to change the base?
Conversation
Hi @yidingww!, thanks for the Pull Request The pull request title isn't properly formatted. We ask that you update the pull request title to match this format, as we use it to generate changelogs and automate releases.
To Fix: You can fix this problem by clicking 'Edit' next to the pull request title at the top of this page. Read more about contributing to ESLint here |
shared/configs.ts
Outdated
} | ||
}) | ||
|
||
return flatGlobs.filter(glob => !unmatched.includes(glob)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the order of ignore and unignore might matter how it work. For the must accurate result, we might need to vendor ESLint's walker here: https://github.com/eslint/eslint/blob/5db226f4da9ad7d53a4505a90290b68d4036c082/lib/eslint/eslint-helpers.js#L216
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@antfu I just updated the PR
I took a different approach, cos i realised that @eslint/config-array
has a very convenient isFileIgnored
here, we can use this to decide if a file is ignored, and that should fix the issue entirely.
I don't think we need to vendor the eslint-helper since it's not exported and there are a long chain of dependencies in eslint's implementations.
0420d93
to
470d160
Compare
shared/configs.ts
Outdated
// push negative globs except for unignore globs | ||
result.globs.push(...negative.filter(glob => !glob.startsWith('!'))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you might also want to push negative unignore globs here, basically all matched globs. There's a comment here where I made that switch, and I think including them causes the UI to be more clear to the user since it indicates that the globs matched, and the user can then interpret the "matched-unignore" (vs the unclear/inconsistent greyed out ui that implies it didn't match glob-wise)
shared/configs.ts
Outdated
// only include ignores because of how ConfigArray works internally: | ||
// isFileIgnored only works when only `ignore` exists | ||
// (https://github.com/eslint/rewrite/blob/config-array-v0.19.1/packages/config-array/src/config-array.js#L726) | ||
ignores: config.ignores ?? [], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fwiw, I also added tests that you could bring over if @antfu likes this
approach more. Would help make sure the functionality is identical too!
…On Sat, Dec 28, 2024, 08:16 Wang Yiding ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In shared/configs.ts
<#115 (comment)>
:
> @@ -48,17 +48,32 @@ export function matchFile(
}
configs.forEach((config, index) => {
+ const isFileGlobalIgnored = configArray.isFileIgnored(filepath)
+ let isFileIgnoredInCurrConfig = false
+ if (config.ignores) {
+ const ignoreConfigArray = buildConfigArray([{
+ index: config.index,
+ // only include ignores because of how ConfigArray works internally:
+ // isFileIgnored only works when only `ignore` exists
+ // (https://github.com/eslint/rewrite/blob/config-array-v0.19.1/packages/config-array/src/config-array.js#L726)
+ ignores: config.ignores ?? [],
@antfu <https://github.com/antfu> @comp615 <https://github.com/comp615>
Hi guys, I just updated the PR again here in this commit
On a special note, here in particular, we need to check the current config
as well to make sure the file is not ignored in current config. See inline
code comment for more details
—
Reply to this email directly, view it on GitHub
<#115 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEELRJ7IKXW7UYYCR6T4QD2H2QEPAVCNFSM6AAAAABUF5MR7GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKMRUG4YTGNBUGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
0f63dae
to
06c81e7
Compare
@comp615 I cherry picked your commits over, and updated the solution again, now should be quite accurate |
* @type {Set<string>} | ||
*/ | ||
-const META_FIELDS = new Set(["name"]); | ||
+const META_FIELDS = new Set(["name", "index"]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The patch here is for @eslint/config-array
to work as expected. Currently @eslint/config-array
doesn't allow custome META_FIELDS so a patch is needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is the riskiest part of the PR. As a library maintainer, I probably wouldn't allow it. As a user, I'm all for it :-P
It looks like the upstream PR was closed here: eslint/rewrite#144, so I think it's important to make sure that there's actually a path towards the main-line using this approach. if that author refuses to allow something like this, then we're probably screwed here and need to find a different approach.
@@ -339,7 +339,7 @@ onMounted(async () => { | |||
<div>Ignored by globs:</div> | |||
<div flex="~ gap-2 items-center wrap"> | |||
<GlobItem | |||
v-for="glob, idx of fileMatchResult.globs" | |||
v-for="glob, idx of fileMatchResult.globs.filter(glob => !glob.startsWith('!'))" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we still want to show negative globs here, they are part of the match so again we can let the user figure them out. I think it's most helpful to show everything that matches (positive or negative)
* @type {Set<string>} | ||
*/ | ||
-const META_FIELDS = new Set(["name"]); | ||
+const META_FIELDS = new Set(["name", "index"]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is the riskiest part of the PR. As a library maintainer, I probably wouldn't allow it. As a user, I'm all for it :-P
It looks like the upstream PR was closed here: eslint/rewrite#144, so I think it's important to make sure that there's actually a path towards the main-line using this approach. if that author refuses to allow something like this, then we're probably screwed here and need to find a different approach.
return globs.filter((glob) => { | ||
const matchResult = minimatch(file, glob) | ||
// for unignore glob, we need to flip back the match | ||
return glob.startsWith('!') ? !matchResult : matchResult | ||
}).flat() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMPORTANT: Instead of doing this, see my patch where you should should add flipNegate: true
to the minimatchOpts
Agree that using the actual config files is a more directly and reliable way to match. I don't know the history here, but I assume something like the metadata issue is why it wasn't done this way in the first place? Or perhaps because it seems duplicative to match, and then match globs again anyways. I left a little bit of feedback to clean it up; if I were you, I'd just want to make sure that there's a path forward to removing the "patch" of config-array. But otherwise I think this is great! |
fix #114
The logic of
getMatchedGlobs
needs to be updated:If an unignore glob is matched, and if this glob without the
!
matches any previous ignore globs, all these globs should be unmatched.