-
Notifications
You must be signed in to change notification settings - Fork 788
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
feat(d.ts): improve axe.d.ts types #4081
Conversation
Before shadow dom support string[] was the correct type for the returned selectors. From code we can see that SerialDqElement.selector is used to populate this, so the type should also be the same.
RelatedNode should have the same selectors and the same element reference as NodeResult. These are populated in process-aggregate.js.
I think this was unintentionally changed in dequelabs#3966. From check definitions we can see that many of them don't specify the incomplete message, because they don't have incomplete as a possible result.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for opening this PR. I am really curious what you are using these methods for.
More precise types make it easier to write these function in typescript. With this change, complier knows about this.data, this.async, etc.
Like evaluate and after, matches can also be a string or a function, but this is not currently represented in types.
The rule metadata object expected in this.configure and the one returned by getRules are not the same. From the code we can see that tags and actIds are read from the rule itself and not from the metadata object.
Thanks, I amended the commits with suggestions (+ prettier formatting).
Mostly for custom rules/checks and capturing additional debug information for nodes in results. I think it makes sense for utils commonly used from checks to be available. |
✅ Reviewed for security. |
Thank you again for your contribution @hamax! |
Improve axe.d.ts types based on what we found was missing/incorrect and was needed in our code. I added more details for each change in commit messages (I tried to verify that each change is correct by looking at axe internals). Some of the issues were introduced with a recent update in #3966, which prompted me to look into this more.