-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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 @testing-library/dom
and @types/react-dom
to peer dependencies
#1305
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 7bb03cc:
|
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.
@eps1lon Do we want to push this one forwards after seeing that the latest major release looks ok? |
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 |
Thanks @eps1lon. I've merged from |
@testing-library/dom
and @types/react-dom
to peer dependencies
Does |
AFAIU no, it only uses the You can feel free to remove it if you want. |
@testing-library/dom
and @types/react-dom
to peer dependencies@testing-library/dom
and @types/react-dom
to peer dependencies
We're using semantic-release so we have to stick with what that tool understands. |
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 }} |
Existing setup works for us so I'd rather not experiment. |
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.