Incorrect types are causing errors when using TypeScript with `moduleResolution` set to `node16` or `nodenext`

[wojtekmaj]

• @testing-library/react version: not relevant
• Testing Framework and version: not relevant
• DOM Environment: not relevant

Relevant code or config:

See reproduction

What happened:

Property 'setup' does not exist on type 'typeof import("file:///node_modules/@testing-library/user-event/dist/types/index")'.

Reproduction:

https://www.typescriptlang.org/play?target=99&moduleResolution=99&module=100&jsx=0#code/JYWwDg9gTgLgBAVwM4FMoFEBuKB28BmUEIcA5AAIwpIzA4DmAtADbABGUAhlAJ4D0yNIxTY8pANwAoSYIyiYAOlQwEYABQBKcUA

Problem description:

Incorrect types are causing errors when using TypeScript with moduleResolution set to node16 or nodenext.

This is confirmed by Are The Types Wrong, which shows that "Import resolved to a CommonJS type declaration file, but an ESM JavaScript file.": https://arethetypeswrong.github.io/?p=%40testing-library%2Fuser-event%4014.4.3

Suggested solution:

Rather than shipping one set of types, separately from the codebase, ship types alongside of cjs and esm code.

Not sure if this will help, but @testing-library/react does not have this problem:
https://arethetypeswrong.github.io/?p=%40testing-library%2Freact%4014.0.0
And I can confirm that IRL.

[k2snowman69]

Just spreading awareness, typescript-eslint has dropped node10 support meaning anyone using typescript-eslint@6 or above (which only supports node16 and above module resolution) and @testing-library/user-event (which only supports node10 resolution due to this bug) are incompatible with one another.

@wojtekmaj FYI there seems to be a bug in the typescript playground (not the link you sent but the playground itself) preventing your reproduction from loading correctly. Some additional steps:

1. Go to link
2. Open the tsconfig editor
3. Change the following settings
   1. target=ES2022
   2. module=Node16
4. Close the tsconfig editor

You should now see the error originally mentioned

[kentcdodds]

For anyone looking for a workaround until this is fixed, you can add this to the top of your test file:

import userEventDefault from '@testing-library/user-event'

// https://github.com/testing-library/user-event/issues/1146
const userEvent =
	userEventDefault as unknown as (typeof userEventDefault)['default']

const user = userEvent.setup() // <-- types!

[k2snowman69]

This workaround worked unblocked me and it should be forward compatible whenever it gets fixed.

import UserEventModule from "@testing-library/user-event";

const userEvent = UserEventModule.default ?? UserEventModule;

[kentcdodds]

I just pushed and published a quick fix in @testing-library/user-event@14.5.0. So now you can use a named import:

import { userEvent } from '@testing-library/user-event'

And this won't have the same problems.

We keep the default export for backward compatibility and there's still a bit of an issue with the types masquerading as ESM, but at least this should unblock most folks.

Unfortunately I don't have any more time to improve things more officially.

[sysmat]

• I use 14.5.0 and import { userEvent } from '@testing-library/user-event'; and getting error:

./node_modules/@testing-library/user-event/dist/esm/_interop/dtl.js:3:61-73 - Error: export 'default' (imported as 'def__default') was not found in '@testing-library/dom'

[michaelperrin]

I have the same error as @sysmat when running StoryBook with version 14.5.0 of the @testing-library/user-event library. I will try to provide more details about that issue.

[yannbf]

Hey @kentcdodds as others have stated, this release ended up having unfortunate side effects.

I created an issue with reproduction steps here: #1160

@michaelperrin (and any other Storybook users): I just released v0.2.1 with a temporary fix for this issue.