I am stealing an example of an existing custom rule for this as exact use cases vary, however, the foundation of checking tags for the presence of x attribute on y tag remains the same. I think this would be an incredibly valuable template to have because there are plenty of cases where making sure x attribute is in y tag would prevent lots of issues from cropping up. It also seems like it would be relatively easy to implement since it’s the inverse of an existing template.
–
This rule checks that the specified attributes ARE present in HTML tags.
Noncompliant Code Example
Expected attribute list of: a.name:
< a href=“blah .com” > ← Noncompliant; name attribute is not used in “a” tag.
Compliant Solution
< a href=“blah .com” name=“Blah link” > ← Compliant ; name attribute is used in “a” tag.
Parameters
attributes Comma-separated list of tag.attributes that are expected. E.G. a.name expects a “name” attribute in an “a” tag.
Type: Bug ← Severity determined by use case, could be info/low/med/high/crit depending on how critical the attribute’s presence is in the tag.
If there is a way to achieve this kind of rule without creating a new custom rule I am all ears, I tried finding a deprecated rule that may be able to achieve the same result but wasn’t able to find anything.
We have similar requirement. We use Cypress.io to do our automation testing and their recommended best practice is to have a data-testid as a property of all input elements (input, anchor, button, etc). We would like to have Sonar flag this as a code smell if it’s missing.
We are not big fans of template rules, we prefer to have a set of rules with clear use-cases. Also if controlling a.name (as an example) is valuable for your team, it might be valuable for another.
Could you list the cases of tag-attributes you want to be alerted to and why?
Hey, thank you so much for the response @Lena. I just wanted to get a response back so you knew I was aware of your question, I am going to bring this up with the team that was requesting this feature. As far as I’m aware this also had to do with testing and there were required attributes for the tests to function properly. They were hoping since sonar had the inverse as a template it would be easy to implement as a template as the tags varied widely per application depending what was being tested.
Let me get back to you with more specifics and thank you again for responding to this, they’ll be excited to hear there was a response.