Describe the feature you'd like:
While looking into optimizing my test suite, I discovered that @testing-library/jest-dom's aria-query dependency is relatively heavy. According to console.time + console.timeEnd, it takes 15-20ms just to require('aria-query'), compared to 0-2ms for other @testing-library/jest-dom dependencies. By itself, this isn't a lot, but since it has to be done for each Jest test suite and a project may have hundreds of Jest test suites, it adds up.
Suggested implementation:
aria-query's implementation uses a large number of individual .js files and contains ARIA details that aren't needed by @testing-library/jest-dom. If @testing-library/jest-dom's ARIA checks are worth keeping and it doesn't want to duplicate aria-query's logic, then one possible implementation would be to add a build step that creates a static JSON file with only the needed information; importing this single JSON file at runtime should be noticeably faster than the current logic.
I can further explore this possibility if there's interest.
Describe alternatives you've considered:
Status quo - slightly slower tests
Teachability, Documentation, Adoption, Migration Strategy:
Not user-visible
Describe the feature you'd like:
While looking into optimizing my test suite, I discovered that @testing-library/jest-dom's aria-query dependency is relatively heavy. According to console.time + console.timeEnd, it takes 15-20ms just to
require('aria-query'), compared to 0-2ms for other @testing-library/jest-dom dependencies. By itself, this isn't a lot, but since it has to be done for each Jest test suite and a project may have hundreds of Jest test suites, it adds up.Suggested implementation:
aria-query's implementation uses a large number of individual .js files and contains ARIA details that aren't needed by @testing-library/jest-dom. If @testing-library/jest-dom's ARIA checks are worth keeping and it doesn't want to duplicate aria-query's logic, then one possible implementation would be to add a build step that creates a static JSON file with only the needed information; importing this single JSON file at runtime should be noticeably faster than the current logic.
I can further explore this possibility if there's interest.
Describe alternatives you've considered:
Status quo - slightly slower tests
Teachability, Documentation, Adoption, Migration Strategy:
Not user-visible