Chore: Move @testing-library/dom to peerDependencies

[jackw]

This PR makes @testing-library/dom a peerDependency allowing projects to define the version of the package they require. I tested this by building and publishing locally and after install tests continued to run.

Fixes: #70

[jackw]

@romgain I'm sorry for the ping but could you take a look at this PR when you've time. We have multiple projects using this package and have needed to set the resolutions field in package.json to circumvent issues with @testing-library/dom being a dependency.

[romgain]

Hey @jackw !

Thanks for your contribution. I think a better solution would be to widen the version range for @testing-library/dom instead of moving it to be a peer dependency (it is a direct dependency after all :))

Would you mind giving that a go?

Thanks again!

[jackw]

Sorry for the late reply @romgain .

Thanks for your contribution.

You're most welcome. This package is super helpful!

I think a better solution would be to widen the version range for @testing-library/dom instead of moving it to be a peer dependency

Based on the issue I'm not sure widening the range is going to solve the problem people are facing. Currently the version range is anything greater than @testing-library/dom@7.0.0 which means on install it will pull and use the latest version of @testing-library/dom. It has no upper limit which could be problematic for consumers if there are breaking changes in any major versions. e.g. @testing-library/dom@9.0.0.

If a project is already depending on @testing-library/dom@7.31.2 I suspect the projects maintainers want to make sure that the tests run using that version. However based on the issue it looks like select-event will resolve to its own version which can cause tests to fail. The only way I know of to avoid these resolution conflicts is to use peerDependencies.

it is a direct dependency after all

I think the general consensus with peerDependencies is that they should also be added to devDependencies otherwise builds and tests won't work. Many packages like eslint configs or react component libraries have direct dependencies as peerDeps and rely on this approach to help consumers avoid pitfalls of resolution conflicts.