Enzyme: 2.8.1 fails with "Cannot find module 'react-test-renderer/shallow'"

[jwalton]

Downgrading to 2.8.0 fixes it.

[jwalton]

Read the README. :P

[pscanf]

This is a breaking change, it shouldn't be shipped in a patch release!

[ljharb]

@pscanf If you're on React 15.4, it doesn't change anything. If you're on React 15.5, it's a bugfix, because React 15.5 had a breaking change.

[jwalton]

The problem is, if your package.json lists react: "^15.4.0" and enzyme: "^2.8.0", then yesterday your module was passing tests on travis, and today it is not, because you have upgraded to the new react and the new enzyme without actually doing anything.

[ljharb]

Yesterday your module wasn't passing tests because it was upgraded to React 15.5 (due to the semver range), and the new console warnings were failing your tests (assuming you were being a responsible developer and failing your tests on propType warnings).

[jwalton]

I do, in fact, fail on proptype warnings, but not on other warnings. My tests were passing fine. :P

Maybe we could change this bit to something like:

    if (REACT155) {
      try {
          // eslint-disable-next-line import/no-extraneous-dependencies
          shallowRendererFactory = require('react-test-renderer/shallow').createRenderer;
      } catch(err) {
          shallowRendererFactory = TestUtils.createRenderer;
      }
    } else {
      // eslint-disable-next-line import/no-extraneous-dependencies
      shallowRendererFactory = TestUtils.createRenderer;
    }

?

[ljharb]

Then there'd be no way to warn users that they're missing a required dependency for React 15.5+.

[jwalton]

Well, there is, because they'll still get the warning that react displays
when the module is required. Or you could even print your own warning
there, in the catch block, to console.error. And it's technically not a "required" dependency
until react 16.

[pscanf]

Being on [email protected] and [email protected] is ok (this was my situation this morning), while [email protected] + [email protected] fails (my current situation).

and the new console warnings were failing your tests (assuming you were being a responsible developer and failing your tests on propType warnings)

I don't agree, react prints warning _specifically not to break things_, so enzyme shouldn't break things because _anyway react would print warnings_.

It might not a big deal I guess (at least for me, since I was updating dependencies anyway), but I would see it as a breaking change nonetheless (which can cause a bit of frustration, sorry for the slightly stormy comment above).

[tomjal]

Just adding react-test-renderer dependency fixes everything for me.

[sorahn]

@tomjal's fix worked for me.

[ljharb]

@pscanf warnings do break things; that's the flawed logic that leads to adding new warnings in a semver-minor.

[lxe]

Just adding react-test-renderer dependency fixes everything for me.

As much as I love this fix, it's not scalable across the millions of monthly installs enzyme and react get. Fixes should follow semver conventions.

[ljharb]

@lxe they did. React 15.5 shipped a change that was subjectively either breaking or minor, which broke some subset of users and libs. enzyme had two choices here: ship a patch that fixes things for those that React 15.5 broke (causing breakage for those users who weren't broken with React 15.5); or ship a semver-major and leave users on the current major line screwed, and forced to adapt to the React breakage (and thus accommodating those users who weren't broken with React 15.5).

semver does not strictly dictate whether "console warnings" are semver-major or not, as such, considering them breaking or non-breaking are both a valid choice.

[openjck]

Without taking sides, I'll say that the semver folks would probably be happy to discuss any ambiguities in a GitHub issue and update their guidelines if necessary.

[ljharb]

@openjck the issue is on what constitutes "API" - the document says "For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself." however I claim that the API consists of "anything that's programmatically observable". Additionally, that document does talk about deprecations being in documentation; React adds deprecations in a semver-minor observably in the code, which I believe constitutes an API change.

[jwalton]

React 15.5 shipped a change that was subjectively either breaking or minor, which broke some subset of users and libs.. enzyme had two choices here: ship a patch that fixes things for those that React 15.5 broke (causing breakage for those users who weren't broken with React 15.5); or ship a semver-major and leave users on the current major line screwed, and forced to adapt to the React breakage (and thus accommodating those users who weren't broken with React 15.5).

React 15.5 shipped a change that was objectively a minor change. It adds a console.log, which isn't even present in production builds. It affects absolutely nothing for my users.

Enzyme had a third choice; do exactly the fix I proposed above. With that fix, if you had 15.5 but hadn't gotten around to doing all the 15.5 fixes and things were working, Enzyme would have had a minor patch and things would have kept working. If you had 15.5 and you were a "responsible developer" whose tests break for any console logs, then when Enzyme referenced TestUtils.createRenderer, React would have logged the warning, and tests would have broken, but it would have been React breaking them, not Enzyme. If you had React 15.5 and you did all the 15.5 upgrades, then Enzyme would have happily chugged along with no warnings, and all would be well. Enzyme would work correctly in all cases, which is the definition of correct software.

I'm not sure why a major version would leave anyone "screwed" - it would have let people know they needed to do something when david told them there was a package that needed upgrading. I'd much rather get a notification from david that I need to do something some time next week than a wall of red from travis-ci for all my various projects on the day before my code freeze.

[tiriana]

I'm using react ^0.14.8 (I know - old) and it also affected me. I downgraded enzyme to ~2.7.1 and things got back to normal.

I'm not so much up to date with news in react, but imo if external libs, depending on enzyme, work with enzyme 2.8.0 (@jwalton proposed downgrading to this version as a solution in first comment) and not 2.8.1 then it sounds like breaking changes for me. Not a patch.

I just hope I'll be able to use enzyme in future versions, b/c I won't be able to update my react any time soon unfortunately.

[tiriana]

@jwalton adding react-test-renderer didn't work for me - I got another error: Cannot find module 'react-dom/test-utils'. Just FYI.

I mentioned @tomjal in prev version of my comment by mistake - I have no idea how autocomplete lead me to do this :-)

[shahzainb]

Just to re-iterate from @tiriana's point, we are also using React 0.14.8 and enzyme ^2.2.0. Everything was working fine until enzyme 2.8.1 shipped yesterday. Our react version didn't change. Downgrading and fixing version to 2.8.0 solved our problem too.

[jwalton]

0.14.8 works for me. If you open a new folder and try:

npm install react@^0.14.8 react-dom@^0.14.8 react-addons-test-utils@^0.14.8 [email protected]
node -e "try{require('enzyme'); console.log('pass');} catch(err) {console.log('***FAIL***', err.stack);}"

Does that print "pass" or "fail"? Is it possible you have some dependency that's pulling in react 0.15.5 and causing this? You can npm ls to see if react 15.5 is in there anywhere.

[shahzainb]

So that prints pass, but when running the unit tests through karma, I get this:

13 04 2017 16:56:10.341:ERROR [framework.browserify]: bundle error
13 04 2017 16:56:10.346:ERROR [framework.browserify]: Error: Cannot find module 'react-dom/test-utils' from '<redacted>/node_modules/enzyme/build'
13 04 2017 16:56:10.365:INFO [karma]: Karma v0.13.22 server started at http://localhost:9876/
13 04 2017 16:56:10.373:INFO [launcher]: Starting browser PhantomJS
13 04 2017 16:56:10.430:ERROR [framework.browserify]: bundle error
13 04 2017 16:56:10.430:ERROR [framework.browserify]: Error: Cannot find module 'react-test-renderer/shallow' from '<redacted>/node_modules/enzyme/build'

npm ls | grep react shows me this:

├── @kadira/[email protected] extraneous
├─┬ [email protected]
│ ├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├─┬ [email protected]
│ ├─┬ [email protected]
│ ├─┬ [email protected]
│ └─┬ [email protected]
├─┬ [email protected]
npm ├─┬ [email protected]
ERR!├── [email protected]
├── [email protected]
├─┬ [email protected]
│ ├─┬ [email protected]
│ ├── [email protected]
├─┬ [email protected]

[ljharb]

If it's affecting users without React 15.5 in their trees, then it is definitely a bug that needs fixing, but I'm not sure how it could be.

[jwalton]

That is definitely a mystery. This is a long shot but, @shahzainb do you have any projects npm linked into your tree?

The only place enzyme tries to require 'react-test-renderer' is here, and it's guarded by the REACT155 check which is set here in a pretty non-ambiguous fashion. It's got to be picking up the new react from somewhere... I'm pretty sure my PR would fix this, but only because it's going to try to fall back on the old code.

[azeldis-lv]

The enzyme 2.8.1 upgrade also mysteriously broke builds for me as well (we are running react 15.3.2). I am pinning to 2.8.0

[shahzainb]

@jwalton nope don't have any linked projects, and besides I deleted the whole node_modules directory and did a full install before commenting with the above log of versions, just to make sure :)

I'll debug this further when I get some time.

[NicholasBoll]

This one hit me as well. Luckily I'm used to npm releases breaking things. The CI logs complained. There is a try...catch to attempt to tell me what's wrong, but webpack catches the failed module first. Fortunately webpack tells me which file attempted to make the failed import (enzyme) and sure enough there was a release the same day the error happened.

Found the culprit between 2.8.0 and 2.8.1: https://github.com/airbnb/enzyme/compare/a4c63a19f8648942b3fca72bf34d863cfa0c6dd9...8ab9528668e2b49c769e6fc4879ea710575b7f2f?expand=1

Ideally React would have done a major bump for removing code out to a different dependency and it would be more obvious something would break.

Also it might be possible enzyme to put detection around the use of TestUtils.createRenderer and fallen back to the require('react-test-renderer/shallow').createRenderer statement. That would probably prevent failures for people:

const shallowRendererFactory = TestUtils.createRenderer || require('react-test-renderer/shallow').createRenderer;

[ljharb]

v2.8.2 published. Please comment if you're still having trouble.

[tiriana]

@jwalton About the snippet you pasted - it logged pass in my case.

[tiriana]

@ljharb Thx for quick reaction. But unfortunately I still get this issue: Cannot find module 'react-test-renderer/shallow'.

[ljharb]

@tiriana can you file a new issue, and include your installed versions of react (and react-related things)?

[tiriana]

@jwalton I actually have react 0.14.9, but nothing seems to pull react 15.5

npm ls | grep react
├─┬ [email protected]
│ ├── [email protected]
│ ├─┬ [email protected]
│ │ └── [email protected]
│ ├── [email protected]
│ ├── [email protected]
├─┬ [email protected]
├─┬ [email protected]
├── [email protected]
├── [email protected]

[tiriana]

@ljharb sure thing, will do.

[tiriana]

@ljharb done: https://github.com/airbnb/enzyme/issues/899

[jsg2021]

Sorry, but 2.8.2 still fails

Cannot find module 'react-addons-test-utils' from 'react-compat.js'

      at Resolver.resolveModule (node_modules/jest-resolve/build/index.js:169:17)
      at node_modules/enzyme/build/react-compat.js:143:21
      at Object.<anonymous> (node_modules/enzyme/build/react-compat.js:214:5)

npm ls | grep react
├─┬ [email protected]
│ ├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├─┬ [email protected]
│ ├─┬ [email protected]
│ ├─┬ [email protected]
│ └─┬ [email protected]
│ ├─┬ [email protected]
│ │ └── [email protected]
│ ├─┬ [email protected]
│ ├── [email protected]
│ ├─┬ [email protected]
├─┬ [email protected]
├─┬ [email protected]
├─┬ [email protected]
├─┬ [email protected]
│ ├─┬ [email protected]
│ ├── [email protected]
├─┬ [email protected]
│ ├── [email protected] deduped

[azeldis-lv]

Still failing my build too, with react 15.3.2

[jsg2021]

if I add npm i react-test-renderer it passes. Does enzyme not list this dependency? Or is that the consumer's responsibility? How would you conditionally depend on one or the other? Seems like a case for a major version bump of enzyme?

[jsg2021]

I'm trying to find where react-addons-test-utils used to come from... to find where react-test-renderer should go :/

[ljharb]

See the readme; you need to explicitly add it.

[jsg2021]

oh :) sorry

[paibamboo]

Upgrading enzyme from 2.8.0 to 2.8.1 or 2.8.2 without upgrading React breaks my build, too.

The error is
Cannot find module 'react-dom/test-utils'

I'm using react 15.4.x. and react-dom 15.4.x

---

Ok, I figured out, you need react-dom 15.5.x for react-dom/test-utils

[aweary]

@paibamboo it shouldn't attempt to require react-dom/test-utils unless you're using React >=15.5.

[GreenGremlin]

Why is react-test-renderer not declared as as peerDependency? I understand it's only required for [email protected], but I don't see the problem with declaring it.

[ljharb]

Declaring it forces everyone to install it, even if they're not using v15.5.

[ZebraFlesh]

2.8.2 still fails for me where 2.8.0 worked. I'm using react, react-dom, and react-addons-test-utils all versioned at 15.4.2; karma 1.7.0, and webpack 2.1. The way I finally made this work was to extend my webpack externals object to be the following:

externals: {
    'react/addons': true,                      // pre-existing at enzyme 2.8.0
    'react/lib/ExecutionEnvironment': true,    // pre-existing at enzyme 2.8.0
    'react/lib/ReactContext': true,            // pre-existing at enzyme 2.8.0
    'react-dom/test-utils': true,
    'react-test-renderer/shallow': true
}

I tried a few different permutations with react-test-renderer before settling on this solution:

1. install react-test-renderer, no external -> failed
2. install react-test-renderer, with external -> passed
3. uninstall react-test-renderer, with external -> passed
4. uninstall react-test-renderer, no external -> failed

So clearly listing the package as an external for webpack was sufficient. All of my shallow rendering tests still pass, and even adding a failing expectation such as expect(wrapper).to.have.className('thisDoesNotExist'); fails as expected, so it seems to be working in this configuration?

[noahehall]

@ZebraFlesh solution worked for me

[ljharb]

Sounds like we may need to update the webpack documentation, and then we can close this issue?