feat(lint/noStaticElementInteractions): add rule

[ryo-ebata]

Summary

Enforce that non-interactive, visible elements (such as <div>) that have click handlers use the role attribute.

Implements #527

Test Plan

Added snaps for valid/invalid cases.

Basically, it conforms to the test cases of eslint-plugin-jsx-a11y/no-static-element-interactions, and test cases that cannot be handled by the resources within Biome are handled individually.

ref:
https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/blob/main/__tests__/src/rules/no-static-element-interactions-test.js

[codspeed-hq]

CodSpeed Performance Report

Merging #2981 will not alter performance

_{Comparing ryo-ebata:ryo-ebata/no-static-element-interactions (e99e251) with ryo-ebata:ryo-ebata/no-static-element-interactions (d4b6279)}

Summary

✅ 108 untouched benchmarks

[ryo-ebata]

@unvalley

• feat(lint/noStaticElementInteractions): add rule #2981 (comment)
• feat(lint/noStaticElementInteractions): add rule #2981 (comment)

As this comment states, the following two methods were created to bridge the gap between eslint-plugin-jsx-a11y and Biome

• is_valid_element
• is_invalid_element

However, I thought it was necessary to optimize the Biome definition based on the official documentation, rather than discussing the two options of which way to go.

Is this an issue that should be addressed in this PR?
If necessary, we will address it in this PR, but I think there is an option to address it in another Issue, PR due to the number of elements.

[unvalley]

@ryo-ebata

Is this an issue that should be addressed in this PR?
If necessary, we will address it in this PR, but I think there is an option to address it in another Issue, PR due to the number of elements.

Let's address that in another PR.

[ryo-ebata]

@unvalley
Sorry for the delay in correcting the code in response to your comment...
Please check back as I have responded to your comments and corrected the points you raised!

[unvalley]

I am personally interested in web a11y and would like you to let us continue to develop Biome's a11y rules in the future, may I?

Of course, helps are always welcome 😄

[unvalley]

@ryo-ebata could you apply codegen to pass the CI?

[unvalley]

I left some suggestions but they are nits or for refactor. Thank you!

[ryo-ebata]

@unvalley
Thank you for your suggestion!
I have corrected your point and run the just gen-lint and just gen-bindings commands.

Also, I have an existing nursery rule that fails the snapshot test with my changes, so I'm going to address that with another PR.

[unvalley]

@ryo-ebata There is a regression in useValidAutocomplete/valid.jsx.snap, could you take a look

[ryo-ebata]

@unvalley

There is a regression in useValidAutocomplete/valid.jsx.snap, could you take a look

Okay! I'll address in this PR!

[ryo-ebata]

@unvalley
I addressed to fix regression in useValidAutocomplete/valid.jsx.snap.
08adc60

But one concern has arisen.
The extract_attributes() function can now handle dynamic values by my change. (Previously, if there were dynamic values, extract_attributes() would stop and terminate processing.)

If an attribute value is dynamic, the caller of extract_attributes() must now handle the processing differently. Therefore, we want to return a value from extract_attributes() that indicates whether it's a dynamic value, but since the return type is String, we're currently returning "[DYNAMIC]".

However, if a user actually sets "[DYNAMIC]" as an attribute value, the system will incorrectly interpret it as a dynamic value.

I'd like to consult with you on whether there might be a better approach to this issue....

[unvalley]

@ryo-ebata
The extract_attrs function should correctly return each rule even when it returns function-like attributes.
Returning strings like "[DYNAMIC]" should be avoided unless it is defined in the specification somewhere, instead it should be changed returning enum can clarify the attribute kinds.

This PR is getting longer, so if this takes too long, update the test case and that change is fine in another PR.

[ryo-ebata]

@unvalley

instead it should be changed returning enum can clarify the attribute kinds.

Fixed to return enum, and also fixed a rule that was causing regressions.
Thanks for a lot of reviews, I think this will be my last commit!
201af4f