Skip to content
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

"moduleResolution": "Node16" default/named export bug #1062

Open
jroru opened this issue Sep 19, 2022 · 3 comments
Open

"moduleResolution": "Node16" default/named export bug #1062

jroru opened this issue Sep 19, 2022 · 3 comments
Labels
bug Something isn't working needs specification The desired behavior is not defined yet

Comments

@jroru
Copy link

jroru commented Sep 19, 2022

Reproduction example

Note: unable to provide a codesandbox link due to the inability to control the version of TypeScript used by the IDE

Prerequisites

  1. typescript@4.8.3
  2. @testing-library/user-event@14.4.3
  3. package.json type: module
  4. tsconfig moduleResolution set to Node16
// tsconfig
{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "moduleResolution": "Node16"
  }
}

Expected behavior

userEvent should be the default export of the module

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

userEvent.click(...);

Actual behavior

userEvent is exported as a named export called default

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

userEvent.default.click(...);

User-event version

14.4.3

Environment

Testing Library framework:

JS framework:

Test environment:

DOM implementation:

Additional context

This may be invalid for Node 16's ESM spec.

I suspect changing it to the following will resolve the issue:

import {userEvent} from './setup';
export default userEvent;
@jroru jroru added bug Something isn't working needs assessment This needs to be looked at by a team member labels Sep 19, 2022
@jroru jroru changed the title Export as default "moduleResolution": "Node16" default/named export bug Sep 19, 2022
@jroru
Copy link
Author

jroru commented Oct 11, 2022

Changing the syntax did not resolve the issue, but importing a named export did. Created a PR #1070 which adds a named export for userEvent.

@sachinahya
Copy link

This happens because the name of the types file ends with .d.ts which, according to its closest package.json, causes TypeScript to be treated as a types file that defines a CommonJS module.

If I put a package.json file in ./dist/types with "type": "module" then the type errors go away, and the .d.ts file gets treated as ESM. Though I guess this could break the types if you try and require it.

@ph-fritsche ph-fritsche added needs specification The desired behavior is not defined yet and removed needs assessment This needs to be looked at by a team member labels Nov 14, 2022
@mzaharie
Copy link

mzaharie commented Nov 23, 2022

There's also this problem when you need the type of the return type of the setup method. I have to do either of the following:

import { UserEvent } from '@testing-library/user-event/dist/types/setup/setup';
function myHelper(user: UserEvent) { ... }

LE: ☝️ still has eslint error saying that import is not good
or

function myHelper(user: ReturnType<typeof userEvent.setup>) { ... }

I'd like UserEvent to be a top level export

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs specification The desired behavior is not defined yet
Projects
None yet
Development

No branches or pull requests

4 participants