-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
disable validation with magic comments #3351
Conversation
I think this seems reasonable enough, and is a more user-friendly thing to do than writing a custom Do we want to worry about a way to disable warnings that occur in |
Yeah, not sure about documentation. Needs some thought. Looking through the code, there are only a handful of warnings that can arise from within
In
Elsewhere:
I'm not sure if there's any real value in being able to disable those warnings — with the possible exception of the Separately, I wondered about having a central registry of warnings, since they're a bit scattered around at the moment. That way, we could check that someone wasn't trying to ignore a non-existent warning. |
@Rich-Harris How do we find out the identifier for the warnings (e.g. Specifically, how do I find out which one to use for this warning:
|
@matryer they're in the svelte compiler: https://github.com/sveltejs/svelte/blob/master/src/compiler/compile/nodes/Element.ts#L668 (search for the warning text) |
vscode correctly reporrts the identifier for the warning: where as the message from the console is just:
Ideally the warning identifier could appear on the console message too |
@Rich-Harris Hi. Can you answer my question, please? Why do you add a feature and later add a feature to disable it? Is it a smart thing to do? |
This is an alternative to #1861 with more specificity.
The idea is that you can add a comment like this...
<!-- svelte-ignore a11y-missing-attribute -->
...and it will ignore any
a11y-missing-attribute
warnings on the next non-text, non-comment node (and any of its children). That includes{#if ...}
etc and components.So in a case like this...
...we'd get an accessibility warning for the first
<img>
but not the second or third, and we'd get a separate warning for the<marquee>
.Multiple codes can be passed at once:
They can be separated by newlines:
They can be stacked:
And they accumulate (i.e. earlier ignores are not cancelled out by newer ignores):
Thoughts?