V12.0

[pierrezimmermannbam]

The prs #1244 and #1244 have been merged, it looks like we're almost ready to ship v12! Are there any other changes we'd like to merge before publishing a new release ? Before releasing we need at least to:

• merge a pr to prepare release that would unflag the breaking changes and remove legacy code
• update the default value for includeHiddenElements to false?

Do you see anything else?

@MattAgn @mdjastrzebski @AugustinLF

[thymikee]

• release notes
• migration guide
• blog post maybe?

[mdjastrzebski]

@pierrezimmermannbam Thanks for creating this issue, indeed we should coordinate with the plans for v12.

Let's give us couple of days to reflect if we would like to ship any other feature / breaking change with v12.

[AugustinLF]

I think there's a typo, you linked twice the same PR in the notes.

If you'd like, we could publish an RC and I could run it on my test suite to see the impact, we have about ~900 rtl tests.

[mdjastrzebski]

1. I think we should finish our a11y improvement effort, by implementing byRole queries don't find element that don't have an explicitly set accessibilityRole prop #1130. That will require some research on how RN + iOS/Android treat different base controls with and without explicit roles. Maybe we can split it by component, so that any of us having limited spare time could contribute e.g. a research and PR for single component?

2. We need to update documentation to reflect changes connected with useBreakingChanges features.

3. Otherwise, from the small things that could also be fixed before v12:

• fix act typing, as discussed in Typescript act() got warning 'await' has no effect on the type of this expression. #1276 - this seems to be relatively annoying bug for some users.
• deprecate byA11yState & byA11yValue - chore: deprecate some a11y queries #1226 - it's my work in progress, but due to regular work I do not have enough time to actually finish it

4. Other interesting APIs can wait utill after v12, as it would not be breaking:

• userEvent feat: userEvent implementation #1119 is an additional API, so would require minor versions updarte
• fireEvent event object no Jest preset installed with 7.2.0 #719, this is an interesting one, I've started [WIP] feature: fireEvent default event object #1258 but also lacked time to finish it

5. Open ideas:

• Should we use v12 to extract and remove flow types as in Call for maintainers: Flow types #1208?

Wdyt @thymikee @AugustinLF @pierrezimmermannbam @MattAgn? Looking forward for your earnest feedback.

[thymikee]

I'm down. Regarding 5, I'd try to stick with the flow types for a little longer, even if we don't update all the typings (or we just stop doing it altogether now). If there's interest from the community, they'll send PRs. If not, it's gonna be a sign that no one is hurt from lack of proper Flow types and we can get rid of it.

[pierrezimmermannbam]

We should definitely update the documentation regarding the breaking changes that will be introduced and have a migration guide. I also think it'd be a good idea to fix the act typing and deprecate byA11yState & byA11yValue queries before releasing.

I'm not sure about #1130 though, I feel like it's not very clear yet where we want to go with this and it may take some time before being implemented. Also it's not really related to the other breaking changes so I don't see any inconvenient on releasing this later. I think that the sooner these breaking changes are released the better, both because it should make migrations easier (either users directly use newest version and never have to go through migration or they don't have as many tests that may break) and to get rid of those useBreakingChange instances in the code, wdyt @mdjastrzebski ?

[mdjastrzebski]

@pierrezimmermannbam makes sense. My goal for this release is not to omit any breaking change that is worth making. How about #1289? Current container API feels incorrect, and changes here would be breaking.

[MattAgn]

Agreed, we should include the fix for container since we also merged the PR about all queries returning host elements. It's all more consistent now

[MattAgn]

I agree with your 4th point, userEventand fireEvent issues will take some time to be implemented and should not block the major release