Rule conflict between `no-invalid-aria-attributes` and `no-unnecessary-concat`

no-invalid-aria-attributes was recently patched to allow for handlebars as acceptable for aria attributes, #2389 e.g.: <div aria-label="{{@name}}"></div>

However no-unnecessary-concat prefers <div aria-label={{@name}}></div> but no-invalid-aria-attributes marks this as invalid without the quotes. Both however correctly evaluate to a string.

It seems like no-invalid-aria-attributes should be aware of no-unnecessary-concat requirements – opening this issue per https://github.com/ember-template-lint/ember-template-lint/pull/2389#issuecomment-1053609716

[rrenno]

In my effort to distill this down into a base case I think I over generalized the issue. Each incorrectly flagged instance contains a conditional – which I believe should not be flagged by the linter, correct?.

E.g. aria-label={{if @label @label @placeholder}} aria-label={{unless @label @label @placeholder}}

addon/components/zb-input/template.hbs
  16:4  error  The value for aria-label must be a string.  no-invalid-aria-attributes
  34:4  error  The value for aria-label must be a string.  no-invalid-aria-attributes

Switching to: aria-label="{{if @label @label @placeholder}}" aria-label="{{unless @label @label @placeholder}}" “Fixes” the no-invalid-aria-attributes error but then throws

addon/components/zb-input/template.hbs
  20:19  error  Unnecessary string concatenation. Use {{if @label @label @placeholder}} instead of "{{if @label @label @placeholder}}".  no-unnecessary-concat
  36:19  error  Unnecessary string concatenation. Use {{unless @label @label @placeholder}} instead of "{{unless @label @label @placeholder}}".  no-unnecessary-concat

I’m also noticing a similar issue with conditionals and aria-describedby when conditional without quotes is used. e.g.

addon/components/zb-input/template.hbs
  33:4  error  The value for aria-describedby must be a list of strings that represent DOM element IDs (idlist)  no-invalid-aria-attributes

Sorry for the misdirection, let me know if I can help clarify further.

[drewlee]

@judithhinlung As discussed earlier, I think we need to make the rule more permissive in how it handles mustache statements. They may evaluate into any number of values or types at runtime, so I don’t think we have an accurate means of making that assessment just from the template alone.