Deep imports causing an error in @web/test-runner

[remcovaes]

Reproduction example

https://github.com/remcovaes/web-test-runer-with-user-event

Prerequisites

1. Clone repo https://github.com/remcovaes/web-test-runer-with-user-event
2. npm install
3. You might have to initialize Playwright
4. npm run test

Expected behavior

Working library

Actual behavior

the following error: SyntaxError: The requested module './../../../../../dom/dist/helpers.js' does not provide an export named 'getWindowFromNode'

User-event version

14.4.3

Environment

Testing Library framework:

JS framework: none

Test environment:

• @web/test-runner v0.14.0
• @web/test-runner-playwright v0.8.10

DOM implementation: Running in a chromium

Additional context

See the file @testing-library/user-event/dist/esm/setup/setup.js and import import '@testing-library/dom/dist/helpers.js';. This will work for commonjs as the file that is import using a deep import is commonjs. In the @web/test-runner, rollup and esbuild plugins are used to bundle (technically not actual plugins, but they work similar). Doing deep imports of commonjs files, throws the build of, causing the error as described above.

Possible fix is to remove all deep import from @testing-library/user-event and only import the stuff @testing-library/dom exposes via the main and module in the package.json. This will make sure that bundlers are able to pick the correct version.

[ph-fritsche]

As I'm currently rewriting our test environment, I stumbled over this too.

Workaround: add https://github.com/rollup/plugins/tree/master/packages/commonjs to your plugins.

[remcovaes]

@ph-fritsche that would work for a 'normal' rollup build, but when used in @web/test-runner it does not work. The only workaround I have is to re-bundling with a separate rollup build myself. It would help a lot of this issue gets fixed to reduce the complexity of these things.

[ph-fritsche]

I agree, getting rid of these imports would be nice.

This is mostly a matter of code duplication and domains.

Ideally the typing and fixes would be applied in dom-testing-library and it would export some more utils. But it is not written in TS yet. So rewriting the modules would probably be better than adding complexity to the separately maintained types.

So I'll probably just add those modules here.