Cannot find module 'pretty-format'

[losvedir]

• @testing-library/react version: 10.2.0
• Testing Framework and version:
  • @testing-library/dom version 7.9.0
  • jest version 25.5.4
• DOM Environment:
  • jsdom version 15.2.1
  • react version 16.13.1
  • node version 13.6.0
  • typescript version 3.9.3

What you did:

Dependabot upgrade of @testing-library/react from 10.0.4 to 10.2.0.

What happened:

In CI, our npm script that invokes tsc --noEmit fails with the following:

➜  assets git:(dependabot/npm_and_yarn/assets/testing-library/react-10.2.0) npx tsc --noEmit
node_modules/@testing-library/react/types/index.d.ts:3:54 - error TS2307: Cannot find module 'pretty-format' or its corresponding type declarations.

3 import {OptionsReceived as PrettyFormatOptions} from 'pretty-format'
                                                       ~~~~~~~~~~~~~~~

Problem description:

It can't find pretty-format. I do see pretty-format in my package-lock.json, version 25.5.0. It might be the "corresponding type declarations" that the error is flagging? I notice this line was added in #690, which finagles the type definitions a bit, though I don't totally understand the PR.

It could be that I'm supposed to update my package-json with a new dependency of some sort?

[kentcdodds]

Hey @samtsai, do you have any ideas here?

[samtsai]

@losvedir I'll have to setup a Typescript project that uses react-testing-library unless you have a repo I can test out. The main goal was to bring in the typings for this library without having to add too many new dependencies, but maybe we'll need to add pretty-format as a dependency in this project.

[losvedir]

Oh yeah, I forgot our repo that this is failing on is open source. Here's the dependabot PR that's failing. You should be able to check out the dependabot/npm_and_yarn/assets/testing-library/react-10.2.0 branch and see the failure. It's an elixir app, but if you cd into assets you should be able to reproduce the failure with npm install and npx tsc --noEmit without dealing with the backend.

[samtsai]

@losvedir can dependabot point to a branch?
https://github.com/testing-library/react-testing-library/tree/fix-pretty-format-import

package.json might be:

"@testing-library/react": "git://github.com/testing-library/react-testing-library.git#fix-pretty-format-import"

[losvedir]

I'm getting the same error:

node_modules/@testing-library/react/types/index.d.ts:3:54 - error TS2307: Cannot find module 'pretty-format' or its corresponding type declarations.

3 import {OptionsReceived as PrettyFormatOptions} from 'pretty-format'
                                                       ~~~~~~~~~~~~~~~

I believe it's because it's listed as a dev dependency, which means that when I run npm install from my root, it won't install it. When I run npm install it will install dependencies and devDependencies for me, but not devDependencies of my dependencies.

I note that in dom-testing-library, on which your PR was based, includes it as a dependency. Perhaps you need to do the same here?

[samtsai]

I'm getting the same error:

node_modules/@testing-library/react/types/index.d.ts:3:54 - error TS2307: Cannot find module 'pretty-format' or its corresponding type declarations.

3 import {OptionsReceived as PrettyFormatOptions} from 'pretty-format'
                                                       ~~~~~~~~~~~~~~~

I believe it's because it's listed as a dev dependency, which means that when I run npm install from my root, it won't install it. When I run npm install it will install dependencies and devDependencies for me, but not devDependencies of my dependencies.

I note that in dom-testing-library, on which your PR was based, includes it as a dependency. Perhaps you need to do the same here?

I've updated the branch to include it as a Dep vs devDep but we're discussing whether or not it's really necessary. We would think pretty-format should be installed from @testing-library/dom since it already lists it as a dependency.

To test again you'll need to blow away the node_module and re-install since it's the same branch name.

[samtsai]

So working with your repo, I was able to upgrade to 10.2.0 as is.

Steps:

1. Blow away node_modules and package-lock.json
2. Re-install node_modules
3. npx tsx --noEmit

I know that removing package-lock.json has its own risk but we'd like not to have to unnecessarily add dependencies to this project when @testing-library/dom already has it as a dependency.

cc @kentcdodds

[losvedir]

Okay, thanks for looking into it. Blowing away package-lock.json might not be a possibility for us, but I think we can always work around it by explicitly adding pretty-format as a dependency ourselves.

[samtsai]

Okay, thanks for looking into it. Blowing away package-lock.json might not be a possibility for us, but I think we can always work around it by explicitly adding pretty-format as a dependency ourselves.

See if next time you do update @testing-library/dom if you get pretty-format as a dep, since its defined as one:
https://github.com/testing-library/dom-testing-library/blob/master/package.json#L44

[losvedir]

@testing-library/dom did have the dependency; however it was in its own node_modules:

my_app
|- node_modules
   |- ...
   |- @testing-library
      |- react
         |- node_modules
            |- ...
      |- dom
         |- node_modules
            |- ...
            |- pretty-format

Meanwhile, TypeScript's module resolution logic is as follows:

However, resolution for a non-relative module name is performed differently. Node will look for your modules in special folders named node_modules. A node_modules folder can be on the same level as the current file, or higher up in the directory chain. Node will walk up the directory chain, looking through each node_modules until it finds the module you tried to load.

That means, for @testing-library/react it would look in my_app/node_modules/testing-library/react/node_modules and my_app/node_modules, and would not find it the sibling /dom tree.

I understand that npm tries to install dependencies as flat as possible, in the top-level node_modules directory, but I think if dependencies have conflicting requirements, each dependency will get their own copy in their own node_modules.

So I think the situation is that I had some other dependency with a conflicting requirement for pretty-format, and so both that dependency and @testing-library/dom installed pretty-format in their respective node_modules folders, not in the shared top-level node_modules folder. Therefore @testing-library/react, which is trying to rely on @testing-library/dom's version, wasn't able to find it.

Ultimately, I went with your proposed solution of just blowing away package-lock.json. In doing so, it re-ran the dependency resolution, and this time a single version of pretty-format satisfied all my dependencies, so it installed it into the top-level node_modules folder, and @testing-library/react's implicit reliance on it works. However, it might not work for someone else with different dependencies, I think.