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: Move @types/react-dom to optional peer dependencies #1305
base: main
Are you sure you want to change the base?
Conversation
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 c4b764e:
|
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.
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?
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? |
Sure thing, I'll get to it later this week. |
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. |
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 `foo` and `@types/foo` they have.
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
.@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.