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
feat: add method isFileConfigured
#7
base: main
Are you sure you want to change the base?
Conversation
856419a
to
49f8c9a
Compare
I think we should revisit the expected behavior of
So then we could do: const isFileConfigured = !isFileIgnored && !isExplicitMatch; |
Sounds good 👍🏻I can change the methods and update ESLint to see how that works in practice. This will be a breaking change. |
@mdjermanovic what do you think of #7 (comment)? |
The current humanwhocodes/config-array#138 (comment). In ESLint, we're using Now, before changing the behavior of Edit: I tried making an example where the current behavior would be easily observable with |
Now it's all coming back to me. :) So So then we are really talking about modifying |
On closer look at the implementation, I think that
or some combination of the above. Currently, |
Yeah, while it can be argued that 3. is a subset of 2. because all patterns are considered relative to the base path so no pattern can match a file outside of it, it would still be good to show a distinct message for 3. |
Can you provide an example to clarify why the specific logic of I tried replacing filterCodeBlock(blockFilename) {
- return configs.isExplicitMatch(blockFilename);
+ return configs.getConfig(blockFilename) !== void 0;
} and all tests we have in eslint/eslint are still passing. |
I believe the case was when we had a |
What is the expected behavior in the following case: // eslint.config.js
export default [
{
plugins: {
"my-plugin": {
processors: {
"my-processor": {
// dummy processor that assumes that the whole content of a file is a single ```ts code block
preprocess(text) {
const lines = text.split("\n");
return [{
filename: "foo.ts",
text: lines.slice(1, -1).join("\n")
}]
},
// just increment lines to adjust for the first ```ts line
postprocess(messages) {
const retv = messages[0]; // there's always exactly 1 code block
retv.forEach(message => {
message.line++
message.endLine++;
});
return retv;
}
}
}
}
}
},
{
files: ["**/*.md"],
processor: "my-plugin/my-processor"
},
{
files: ["**/*"],
rules: {
"no-undef": 2
}
}
];
```ts
bar
``` The virtual The current behavior is:
|
Yes, so this is exactly the case I was targeting. IMHO, we should silently skip code blocks that don't have an explicit match. It's quite possible that people won't want to lint every code block, especially if it's not JavaScript. Outputting a warning for every code block that doesn't have a matching config seems likely to only create noise and frustration. Think of a Markdown file that has code examples in multiple languages, most of which ESLint does not lint. |
I agree, but |
Okay, I got confused.
Right, that's what we don't want. So maybe |
This PR adds a method
isFileConfigured
toConfigArray
, to determine if a file has matching configuration or not. This could be used in ESLint to provide a better message for ignored files that don't have a matching configuration.Refs eslint/eslint#18263
This PR introduces the same changes as humanwhocodes/config-array#138, plus the reformatting done by prettier in the commit hook.
See also the discussion in humanwhocodes/config-array#138.