Open zmeyc opened 4 years ago
Good suggestion @zmeyc! Plus I like the idea of offering a syntax consistent with other linting tools.
I will note if you're using the CLI or VS Code extension you can edit your .hintrc
file to ignore specific CSS properties. Some examples here: https://webhint.io/docs/user-guide/hints/hint-compat-api/css/#can-the-hint-be-configured
So for this particular case you could do:
{
"connector": {...},
"formatters": [...],
"hints": {
"compat-api/css": ["default", {
"ignore": ["overscroll-behavior-y"],
}],
...
},
...
}
This is of course different that being able to disable a hint for a specific line or file, but it may work for your scenario.
Another use case for this. See this JSX code:
if (props.doNotRender) {
// hint-disable-next-line <-- this would be great
return <div id="preact_root"></div>;
}
return (
<ErrorBoundary>
<div id="preact_root"><div>
/* ... */
</ErrorBoundary>
)
current error:
Eslint can do this:
// eslint-disable-next-line react-hooks/rules-of-hooks
Thanks for sharing the use case @gianpaj!
@molant and @sarvaje, I'm thinking doing something like this in a hint-agnostic way would likely involve filtering reports after the fact based on location. If we can add to a collection of ignored resources/locations during parsing, we can then remove matching reported problems from the collection before returning. This should also allow us to make this scoped to specific hints, much like eslint. What do you think?
It's definitely a nice feature to add.
If we do this during the walk of the AST, are you planning on subscribing when there is a comment? I don't remember very well all that part of the code, but IIRC it might have to be a bit custom for each parser (with a shared collection as you proposed), right?
Also, what types of directives do we want to support?
// hint-disable(-next-line) hint-1,hint-2
--> JS + JSON5?/* hint-disable(-next-line) hint-1,hint-2 */
--> CSS + JS + JSON5?<!-- hint-disable-next-line hint-1, hint-2 -->
--> HTML// hint-disable-start|end hint-1,hint-2
/* hint-disable-start|end hint-1,hint-2 */
<!-- hint-disable-start|end hint-1, hint-2 -->
@molant, yes I suspect this will have to be a bit custom for each parser, at least for each unique type of AST we work with. So we can probably avoid separate logic for JS vs TS or CSS vs SASS, but we will likely need to handle JS, CSS, JSONC, and HTML.
If we want to align with ESLint I think we'd be looking at these directives (comment format varying as needed for target language):
/* hint-disable(-next)-line hint-1, hint-2 */
/* hint-(disable|enable) hint-1, hint-2 */
🚀 Feature request
It would be nice to be able to ignore a specific line in css. For example, overscroll-behavior-y is missing in Safari and webhint warns about this, but unless I've missed something, there's no way of disabling the warning.
For example, this is how stylelint implements this: https://stylelint.io/user-guide/ignore-code