"Missing React element for debugID" warning when testing components with Jest

[angusfretwell]

Do you want to request a feature or report a bug?

Report a bug.

What is the current behavior?

When testing components, Warning: ReactComponentTreeDevtool: Missing React element for debugID 1 when building stack is shown when calling TestUtils.renderIntoDocument.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar (template: https://jsfiddle.net/reactjs/69z2wepo/).

https://github.com/angusfretwell/reproduce-debugid-warning (npm install && npm test).

What is the expected behavior?

According to #7187 this is an internal warning and shouldn't be displayed.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

• [email protected]
• [email protected]
• [email protected]

I didn't receive this warning on 15.2.0.

[gaearon]

Could this be some sort of a Jest issue (related to mocking?).
In your example, if I put a log in the top level scope of ReactComponentTreeDevtool.js, I see it twice.

I’m not sure if this is normal.

I can also “fix” the issue by moving requires inside the test:

jest.unmock('../../components/HelloWorld');

describe('HelloWorld', () => {
  it('displays the message', () => {
    var React = require('react');
    var ReactDOM = require('react-dom');
    var TestUtils = require('react-addons-test-utils');
    var HelloWorld = require('../../components/HelloWorld').default;

    const helloWorld = TestUtils.renderIntoDocument(<div><HelloWorld /></div>);
    const helloWorldNode = ReactDOM.findDOMNode(helloWorld);
    expect(helloWorldNode.textContent).toEqual('Hello World');
  });
});

I would advise you to file an issue with Jest. It shouldn’t be executing our modules twice.

[angusfretwell]

Thanks for looking into this @gaearon, I will file an issue with Jest.

[cpojer]

Reopening this as this is not a Jest issue. Downgrading React to 15.2.0 makes this warning go away in @angusfretwell's example. @angusfretwell thanks for providing a repo!

@gaearon can you look into this from the React side?

[gaearon]

Hmm, I don't know enough about Jest to solve this in React. The only related change I can think of is that I inlined some requires to this module inside DEV blocks so that it doesn't get bundled to production. Does this cause Jest to execute it twice? Even though it worked before, I can't quite see how module being executed twice can be valid behavior. It doesn't happen in Node or in the browser and CommonJS does not allow this to my knowledge so I can't quite see yet how this can be React's issue.

[gaearon]

(To clarify, yes, I know it's new in React 15.2.1. But it doesn't mean this is a React issue. It just looks like we hit an edge case in Jest that we didn't hit before. But I can try bisecting this if it helps.)

[cpojer]

Jest resets the module registry before each call to it, so it is quite possible that people will end up with two copies of React if they aren't careful. Can you point me to the change in React since the last release?

[gaearon]

Wow, I thought resetting is always explicit.
Then it is probably caused by #7188.
As you can see I had to doctor a few tests to make it pass but I thought those were caused by explicit resetModuleRegistry calls.

I still don't quite understand what is happening. Are lazy requires an unsupported pattern?

[cpojer]

Oh, I see what is happening here now.

Here is how Jest works in open source:

• We call jest.resetModuleRegistry() implicitly in every beforeEach call. When doing require('React') (or import) on the top-level and then require('React') inside of a call to it), they will be fresh copies both times. I suspect the debug module is freshly required from an old version of React which will then go and require new versions of modules it requires itself.

At Facebook here is how Jest works:

• We explicitly call jest.resetModuleRegistry() in beforeEach. Not every test does this, but every test should and I've been hoping to turn the open source behavior on internally as well.
• We use top-level requires but we inline them. const React = require('React') will be removed and inlined into the code. Together with the module registry reset, this works pretty well and every call to it is completely isolated. Previously, the way we required modules in our tests internally was always quite the mess.

What we do at FB is what I'd recommend most people to do however people in open source have decided they want to use ES2015 imports, even in tests and there is not much I can do to stop them. That way they might end up with this confused state.

Jest sets the NODE_ENV to test – could we leverage this in React?

[gaearon]

OK, I think I understand it now.

Seems like we could force those inline requires at the top of the file when NODE_ENV is test. We could then remove this hack when we start using Rollup and no longer need inline requires.

[gaearon]

This will either be fixed by #7245 or #7178, depending on which goes first.
Thank you very much for a good repro case.

[angusfretwell]

Thanks @gaearon!

[gaearon]

Let’s keep it open until either fix gets in.

[mikejoseph]

Anyway to quiet the warnings in the mean time? I have about 5000 of these warnings in my suite which makes it a bit hard to look at the test output.

[gaearon]

As a super temporary fix you can put require('react/lib/ReactComponentTreeDevtool'); at the top level in your tests. I think this should fix the issue. Be sure to remove it when the next version is out 😄 . And only do this in tests.

[mikejoseph]

Thanks for the suggestion :) . FWIW, it doesn't seem to have helped much.

In the mean time we're just dumping STDOUT to a file and inspecting that. Works quite well since the warnings are dumped to STDERR (for anyone with the same problem).

[mthadley]

Along the same lines, you could also do something like npm run test 2>/dev/null if you are in a unix environment.

[mikejoseph]

Face. Palm. Apparently I need more coffee.

Routing ERR to /dev/null works perfectly, as it should. Thanks again.

[gihrig]

I just did a new clone (git hash b496aa5215806f825eed7edbf091970dec17a7f2), into a new directory.

When I npm install and npm test I get 40 errors, all referencing debugID 17. The errors all appear between the first and second test of <FeaturePage />.

Removing all blank lines from the FeaturePage/tests/index.test.js file does not remove the errors.

[nathanmarks]

@tsnieman Wish that were the case on my end! Glad you got it sorted out 👍

[gihrig]

For what it may be worth, I just cloned @tsnieman's repo (git hash 5af07331b4d7e0513794ef6c6b2e585378a896fe) then npm install and npm start the app seems to work as expected.

I must remove --watch from the test script to get any test results to show on screen. Then 70 tests run and pass. There are numerous errors (but no test failures) and no Missing element for React debugID errors.

[aocenas]

If it is any help to anybody, here is probably more minimal boilerplate with the same problem with npm test https://github.com/aocenas/react-starter-kit (e5e0d7fd65f819782873ea0a6b2b7b61271e73b5).

[gihrig]

@aocenas Just cloned (e5e0d7fd65f819782873ea0a6b2b7b61271e73b5), installed and tested, no errors.

Have you recently done a fresh install or deleted node_modules?

npm test

> [email protected] test /Users/glen/Documents/JavaScript/Research/react-starter-kit
> jest --config jest.json

Using Jest CLI v14.1.0, jasmine2, babel-jest
 PASS  __tests__/Clicker.test.js (1.179s)
1 test passed (1 total in 1 test suite, run time 2.451s)

[aocenas]

@gihrig This is me after clean install:

git clone https://github.com/aocenas/react-starter-kit.git
cd react-starter-kit/
npm install
npm test

[09:00:16][react-starter-kit]$> npm test

> [email protected] test /Users/andrejocenas/dev/react-starter-kit
> jest --config jest.json

Using Jest CLI v14.1.0, jasmine2, babel-jest
Running 1 test suite...Warning: ReactComponentTreeDevtool: Missing React element for debugID 2 when building stack
Warning: ReactComponentTreeDevtool: Missing React element for debugID 2 when building stack
Warning: ReactComponentTreeDevtool: Missing React element for debugID 2 when building stack
Warning: ReactComponentTreeDevtool: Missing React element for debugID 2 when building stack
 PASS  __tests__/Clicker.test.js (1.099s)
1 test passed (1 total in 1 test suite, run time 3.389s)

My node --version is v6.3.1, maybe thats the difference?

[gihrig]

@aocenas Just updated to node 6.3.1

OS X 10.11.6
node -v 6.3.1
npm -v 3.10.5
git clone https://github.com/aocenas/react-starter-kit.git
cd react-starter-kit/
npm install
npm test

react-starter-kit glen$ npm test

> [email protected] test /Users/glen/Documents/JavaScript/Research/react-starter-kit
> jest --config jest.json

Using Jest CLI v14.1.0, jasmine2, babel-jest
 PASS  __tests__/Clicker.test.js (0.805s)
1 test passed (1 total in 1 test suite, run time 2.256s)

PS. still get errors as described above after updating to node 6.3.1 and rebuilding node_modules.

[cpojer]

Can you try sticking "persistModuleRegistryBetweenSpecs": true into your config and whether that makes these warnings go away? We are gonna ship with this as a default in the next major of Jest and it is annoying that we haven't done this before.

Jest actually resets all the modules in between calls to it to give even more isolation. So doing something like:

it('works', () => {
  const sum = require('sum');
  sum(1, 2);
});

it('works too', () => {
  const sum = require('sum');
  sum(1, 2);
});

both "sum" modules will actually be different instantiations of the module. So if you don't want to change the option above, you can also inline all your requires manually:

it('works', () => {
const React = require('React');
expect(

).;
});

When we persist the module registry, both of them will be the same (=== is true). The downside is that you might have module local state between tests that is carried over. I think since people decided to predominantly use import statements in new code, this option makes no sense by default any more.

[gihrig]

When we persist the module registry, both of them will be the same (=== is true). The downside is that you might have module local state between tests that is carried over. I think since people decided to predominantly use import statements in new code, this option makes no sense by default any more.

@cpojer You may be onto something here. I'm running Mocha so I can't implement your suggestion, but it got me thinking...

The crop of errors I get occur in the <FeaturePage /> tests. So, I commented out the test function bodies and related imports. Now the FeaturePage tests run and "pass" without errors, but similar errors occur on the <HomePage /> tests, which run just after the FeaturePage tests.

Previous to commenting the FeaturePage tests, the HomePage tests ran without errors. This suggests that the errors are not related to the test, per se, but are (possibly) caused by a resource limitation or conflict of some kind.

[aocenas]

@cpojer in my case the "persistModuleRegistryBetweenSpecs": true helped, no more warnings after changing that setting. But I have only one it() call in my spec so I would assume that the "reseting of registry in between calls to it" does not happen.

Also if I inline my requires into the it() call as in your example, the warning disappears.

[nathanmarks]

@aocenas @gihrig Have you guys seen warning volume like this? Check this build log (worst case is at line 937 in the log): https://travis-ci.org/callemall/material-ui/builds/151227063

Also note that the mocha test suite runs twice, once using node (jsdom for the DOM) and once using karma. There are a TON more debug errors in the jsdom run.

[cpojer]

@aocenas that is because Jest resets the registry before every test. So if you have required React already, it might get re-required (or inline-requires will be re-evaluated).

[gihrig]

@nathanmarks All of the errors I'm seeing occur in one block, whether run local or on Travis, and my test suit only runs once. But then I have only 83 tests.

[levithomason]

This is also occurring without Jest in TechnologyAdvice/Stardust, 100s or 1000s of these errors:

ERROR: 'Warning: ReactComponentTreeDevtool: Missing React element for debugID XXX when building stack'

I checked to ensure React and ReactComponentTreeDevtool are not being called more than once using a console.log as @gaearon used above. Each is called only once at the start of tests.

I've also tried executing a single test file in my test bundle and some errors persists. I have not figured out what exactly causes the error, but it is related to certain tests running in succession as isolating some tests seems to resolve some of the issues.

node                                  v6.2.1
npm                                   v3.9.3

react                                 ^15.3.0
react-dom                             ^15.3.0
react-addons-test-utils               ^15.3.0

karma                                 ^0.13.22
karma-cli                             ^1.0.0
karma-coverage                        ^1.0.0
karma-mocha                           ^1.0.1
karma-mocha-reporter                  ^2.0.0
karma-phantomjs-launcher              ^1.0.0
karma-phantomjs-shim                  ^1.4.0
karma-webpack-with-fast-source-maps   ^1.9.2

chai                                  ^3.3.0
chai-enzyme                           ^0.4.1
dirty-chai                            ^1.2.2
enzyme                                ^2.2.0
mocha                                 ^2.3.3
phantomjs-prebuilt                    ^2.1.7
sinon                                 ^1.17.3
sinon-chai                            ^2.8.0

[nathanmarks]

@levithomason Sounds very similar to what I'm experiencing.

[levithomason]

Aye, I may delve into this further at some point. Right now it is just annoying but not actually breaking anything.

[nathanmarks]

@levithomason Ditto. Next time I look into it I'm going to try track down my root cause rather than trying to create a simple repro, none of the simple repros seem to work.

[quantizor]

The OP error has disappeared for me using the latest build.

[levithomason]

@yaycmyk would you mind posting which versions of which modules you are on?

[quantizor]

[email protected] [email protected]

[gaearon]

I think one of my 15.3.1 PRs fixed this, although I don’t know which one.
I can no longer reproduce this with react-boilerplate.
I used [email protected], [email protected], and [email protected].

[levithomason]

Confirmed 15.3.1 works on TechnologyAdvice/Stardust. Thanks much!

[gihrig]

I can no longer reproduce this with react-boilerplate

I have confirmed this to true, problem resolved! Thank you @gaearon 🎉

[samit4me]

Thank you very much @gaearon, can confirm 15.3.1 resolves the issue.

I spent some time trying to make sense of the issue in the react-boilerplate project. What I found doesn't add much value but I thought it might be worthwhile sharing my findings, it certainly is a curly one.

In the <Img /> tests, the component is shallow rendered twice.

• If you render it once or three times the issues would disappear.
• If you add an additional expect test to the existing test case, the issues would disappear.

I tried many many other scenarios but they did not help.

No warnings

describe('<Img />', () => {
  // it('should render an <img> tag', () => {
  //   const renderedComponent = shallow(<Img src="test.png" alt="test" />);
  //   expect(renderedComponent).to.have.tagName('img');
  // });

  it('should have an alt attribute', () => {
    const renderedComponent = shallow(<Img src="test.png" alt="test" />);
    expect(renderedComponent).to.have.attr('alt', 'test');
  });
});

No warnings

describe('<Img />', () => {
  it('should render an <img> tag', () => {
    const renderedComponent = shallow(<Img src="test.png" alt="test" />);
    expect(renderedComponent).to.have.tagName('img');
  });

  it('should have an src attribute', () => {
    const renderedComponent = shallow(<Img src="test.png" alt="test" />);
    expect(renderedComponent).to.have.attr('src', 'test.png');
  });

  it('should have an alt attribute', () => {
    const renderedComponent = shallow(<Img src="test.png" alt="test" />);
    expect(renderedComponent).to.have.attr('alt', 'test');
  });
});

No warnings

describe('<Img />', () => {
  it('should render an <img> tag', () => {
    const renderedComponent = shallow(<Img src="test.png" alt="test" />);
    expect(renderedComponent).to.have.tagName('img');
  });

  it('should have an alt attribute', () => {
    const renderedComponent = shallow(<Img src="test.png" alt="test" />);
    expect(renderedComponent).to.have.attr('alt', 'test');
    expect(renderedComponent).to.have.attr('alt', 'test');
  });
});