Expand peer dep range of test utils to support RTL 14

[LFDanLu]

Closes

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component).
• Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

RSP

[rspbot]

Build successful! 🎉

• View the storybook
• View the storybook-17
• View the storybook-16
• View the documentation

[snowystinger]

I don't know that we can support both https://github.com/testing-library/user-event/releases?page=3

[LFDanLu]

13 vs 14 of RTL certainly has breaking change, but the actual util functions right now don't have anything specific to 14 within them (only has fireEvent and pointerEventMap, the latter of which is only a object that a user can choose to import/not import for the purpose of providing to their own user setup aka someone on RTL 13 wouldn't use that)

[snowystinger]

We don't make use of any of the things which were breaking?
Sorry, normally I'd check myself and verify. I'll try to find time to.

[LFDanLu]

NP, so the test utils right now is just the stuff in react-aria/test-utils and react-spectrum/test-util, and the only things that use stuff from testing library is https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/test-utils/src/events.ts and https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/test-utils/src/userEventMaps.ts. The first is a fireEvent util so that isn't affected by user-event's breaking changes. The second is a userEventMap that is specific to 14, but is up to the user if they need it or not.

[snowystinger]

Approving

I'm still worried that we can't support both once we start expanding into component specific utilities, but I'm ok with it so long as we're pre-releasing this

[LFDanLu]

I'm still worried that we can't support both once we start expanding into component specific utilities, but I'm ok with it so long as we're pre-releasing this

I agree, it might turn that the component specific utils force RTL 14 but I def want to explore supporting sub-14 RTL at the same time as 14 in my experimental branch.

[rspbot]

Build successful! 🎉

• View the storybook
• View the storybook-17
• View the storybook-16
• View the documentation

[rspbot]

## API Changes

unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any', access: 'private' }
unknown top level export { type: 'any', access: 'private' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'identifier', name: 'Column' }
unknown top level export { type: 'identifier', name: 'Column' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }