-
Notifications
You must be signed in to change notification settings - Fork 1.1k
feat: Move @testing-library/dom and @types/react-dom to peer dependencies
#1305
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
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/domwas moved to a peer dependency and needs to be explicitly installed. This reduces the chance of having conflicting versions of@testing-library/dominstalled that frequently caused bugs when used with@testing-library/user-event. We will also be able to allow new versions of@testing-library/dombeing used without a SemVer major release of@testing-library/reactby just widening the peer dependency.@types/react-domneeds to be installed if you're typechecking files using@testing-library/react.Type dependencies need to match their runtime counterpart.
If
foois a dependency,@types/fooneeds to be one as well.If
foois a peer dependency,@types/fooneeds to be one as well.This is especially apparent if the constraint on
foospans multiple major versions.If we'd make
@types/fooa direct dependency, users couldn't control which major version they get.Package managers would pick the highest.
By moving
@types/footo peer dependencies, users can control which version of@types/foothey have.In our case specifically, you'd get type mismatches of
@types/react-domif we just widen the peer dependency constraint from^18to^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.