Support for ignore / disable comments

[matthias-ccri]

Similarly to eslint, it would be nice to have "ignore" comments, and even "ignore next line" and "disable"/"enable".

I see there is support for @ts-ignore (ref: https://github.com/runem/lit-analyzer/issues/1), which covers a lot of use cases, but not all. It also would be good to document how to use ts-ignore in both the TS and html forms.

I noticed that a ts-ignore comment does not disable the no-missing-element-type-definition rule, as below:

@customElement('foo-fighter')
// @ts-ignore
export class FooFighter extends LitElement {
//           ~~~~~~~~~~
//           'foo-fighter' has not been registered on HTMLElementTagNameMap
//           lit-plugin(no-missing-element-type-definition)(2311)

[ardnejar]

It would be great be able to ignore within the css. @ts-ignore is working for me in html and js, but not within css. Specially: I'm getting error "no-invalid-css" for "text-wrap", which is valid for Chrome and Firefox.

It would also be nice if lit-analyzer didn't consider properties invalid-css when they are wrapped in a supports at-rule.

@supports (text-wrap: balance) {
  h1 {
    text-wrap: balance;
  }
}

[steverep]

The biggest problem with using @ts-ignore as currently implemented is that it ignores every rule in the entire tree, when all you probably need is one or two rules on one element:

return html`
<!-- @ts-ignore Disables all checks on parent and all children -->
<my-parent>
  <my-child .string=${100}>
    <my-grandchild ?boolean=${new Set()}></my-grandchild>
  </my-child>
</my-parent>
`;

The errors in descendants get ignored too. It would be nice to pass some directions in the comment to control what is ignored. For example:

return html`
<!-- @ts-ignore parent-only, lit-plugin/no-missing-import -->
<my-parent>
  <my-child .string=${100}>
    <my-grandchild ?boolean=${new Set()}></my-grandchild>
  </my-child>
</my-parent>
`;

Is this not possible as an extension of the current implementation?

[ynotdraw]

Hello! First off, thanks a bunch for this repo. It's incredibly handy

I am also hitting the issue described above. Is this something y'all would be open to a contribution for? Is there something else we should be doing instead? Any pointers on how this may be solved?