feat: Move @testing-library/dom and @types/react-dom to peer dependencies

[eps1lon]

Closes #1184
Docs: testing-library/testing-library-docs#1384

BREAKING CHANGE:
@testing-library/dom was moved to a peer dependency and needs to be explicitly installed. This reduces the chance of having conflicting versions of @testing-library/dom installed that frequently caused bugs when used with @testing-library/user-event. We will also be able to allow new versions of @testing-library/dom being used without a SemVer major release of @testing-library/react by just widening the peer dependency.
@types/react-dom needs to be installed if you're typechecking files using @testing-library/react.

Type dependencies need to match their runtime counterpart.
If foo is a dependency, @types/foo needs to be one as well.
If foo is a peer dependency, @types/foo needs to be one as well.
This is especially apparent if the constraint on foo spans multiple major versions.
If we'd make @types/foo a direct dependency, users couldn't control which major version they get.
Package managers would pick the highest.
By moving @types/foo to peer dependencies, users can control which version of @types/foo they have.

In our case specifically, you'd get type mismatches of @types/react-dom if we just widen the peer dependency constraint from ^18 to ^18 | ^19. Currently, we're already compatible with the planned React 19 features so all we'd have to do is widen the constraint on release.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 7bb03cc:

Sandbox	Source
react-testing-library-examples	Configuration

[MatanBobi]

Thanks.
Just a thought since we're doing this and bumping a major - lately we're having many issues with DTL version mismatches in RTL and user-event, do we maybe want to think about also move DTL to peerDeps?

[eps1lon]

do we maybe want to think about also move DTL to peerDeps?

I think so. Since DTL is stateful due to the config object, having multiple versions is problematic.

Ideally we wouldn't have the stateful config object to begin with but that requires a large refactor that needs coordination.

We don't need to rush this in this PR though. Could you help out and prepare docs and a commit making that change?

[MatanBobi]

We don't need to rush this in this PR though. Could you help out and prepare docs and a commit making that change?

Sure thing, I'll get to it later this week.

[MatanBobi]

@eps1lon Wdyt about making this change as part of a major too? #1277

Also, here's the PR to move DTL to peer: #1309

[eps1lon]

Also, here's the PR to move DTL to peer: #1309

Just push this commit to this branch. I don't want to go through the alpha branch shenanigans and just ship the major with one PR.

[MatanBobi]

Just push this commit to this branch. I don't want to go through the alpha branch shenanigans and just ship the major with one PR.

Done. I haven't fixed the conflicts though as we have more changes coming to that file.

[MatanBobi]

@eps1lon Do we want to push this one forwards after seeing that the latest major release looks ok?

[eps1lon]

We haven't got any reports recently so this seems safe now. I don't expect bugs that require big changes i.e. if something comes up it's likely small enough to warrant a backport.

Thank you for pushing this @MatanBobi

[MatanBobi]

Thanks @eps1lon. I've merged from main and fixed the conflicts we had so this is ready to be merged IMO.

[eps1lon]

Does feat! do anything for semantic-release?

[MatanBobi]

Does feat! do anything for semantic-release?

AFAIU no, it only uses the BREAKING CHANGE commit message, though I'm trying to follow conventional commit messages:
https://www.conventionalcommits.org/en/v1.0.0/#commit-message-with--to-draw-attention-to-breaking-change

You can feel free to remove it if you want.

[eps1lon]

We're using semantic-release so we have to stick with what that tool understands.

[ph-fritsche]

Does feat! do anything for semantic-release?

If you like to switch to conventional commit, it's the default config here:

      - name: 🚀 Release
        uses: ph-fritsche/action-release@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

[eps1lon]

Existing setup works for us so I'd rather not experiment.