Merge with main library

[ph-fritsche]

Hey, hey guys :) Hope you're doing well!

Why not just to move everything related to interactions to the user-event package and after it's ready to be merged with the main library - do it? IMO it's always great to have one common thing for one concrete purpose in terms of consistency.

Originally posted by @j-u-p-iter in #189 (comment)

[ph-fritsche]

fireEvent won't be removed. And userEvent won't be merged in the near future. There is #183 hanging, but although we resolved quite a few issues in the last couple of months there are also some bugs and feature requests left.

Also there are some ideas how to rewrite substantial parts of the code. See e.g. #638 (comment)
I don't think tackling those as part of a bigger project will be easier. Better let userEvent develop at it's own pace.

Next step of integration will be a better documentation for userEvent as one of the Frameworks in testing-library/docs.

Contributions are welcome.

[j-u-p-iter]

Thank you for your feedback!

[make-github-pseudonymous-again]

I vouch for @testing-library/user-event to remain an additional package. It seems from the package.json peerDependencies key that user-event cannot exist without dom-testing-library, but the converse is not true. And there are valid use cases for not exploiting user-event at all. Keeping these separate facilitates having clear responsibility boundaries for each.

[nickmccurdy]

I think this would be worth reconsidering now that user-event is more stable and has async support (so I no longer have concerns about recommending it to Vue/Svelte/etc. users).

[ph-fritsche]

How do you think integration into other libraries should work?

I'm currently working on #1019 and it will once more increase the infrastructure differences. Therefore I think moving the source e.g. into dom-testing-library will complicate things.

But reexporting the package from the framework libraries might work.

[nickmccurdy]

How do you think integration into other libraries should work?

I'm currently working on #1019 and it will once more increase the infrastructure differences. Therefore I think moving the source e.g. into dom-testing-library will complicate things.

Kent previously made a PR to merge user-event into dom-testing-library, but we closed it because of the async issue. Now that it's solved, I think having similar infrastructure in dom-testing-library (and its forks) would be worth it in the long run, and I can try to help if you're interested.

But reexporting the package from the framework libraries might work.

That has the disadvantage of not working with pnpm or Yarn modern (by default, can be configured). According to Stack Overflow, 27.64% of developers use Yarn. However, this doesn't tell us whether they're using Yarn modern or how they're configuring it.

[ph-fritsche]

I think having similar infrastructure in dom-testing-library (and its forks) would be worth it in the long run, and I can try to help if you're interested.

Yes, when that issue is resolved we can discuss if and how we want to bring those changes into dom-testing-library too.

That has the disadvantage of not working with pnpm or Yarn modern (by default, can be configured).

But we also reexport dom-testing-library in the framework libraries. Might as well do the same with user-event.

[ph-fritsche]

An alternative would be resolve this per git. Add dom-testing-library and user-event as submodules and handle the import/export during build. But this means those libraries need to bump the version for every change in user-event.

[nickmccurdy]

I think having similar infrastructure in dom-testing-library (and its forks) would be worth it in the long run, and I can try to help if you're interested.

Yes, when that issue is resolved we can discuss if and how we want to bring those changes into dom-testing-library too.

Sounds good. I'll reply in #1019 if I can think of more ideas, otherwise I'll still be subscribed to other replies.

That has the disadvantage of not working with pnpm or Yarn modern (by default, can be configured).

But we also reexport dom-testing-library in the framework libraries. Might as well do the same with user-event.

Oh, I didn't think about that. However those libraries could probably use dom-testing-library as a peer dependency if we wanted to prevent issues with strict package managers. That being said, I think there are more benefits to merging the user-event code into dom-testing-library, especially around long term maintenance and promoting best practices.