Cryptic error using webpack v2, webpack-dev-server v2, RHL v3

[nylen]

In the process of upgrading a project to webpack v2, webpack-dev-server v2, react-hot-loader v3, and d3.js v4 (to take advantage of the new tree shaking features), I ran into the following error:

React.createElement: type should not be null, undefined, boolean, or
number. It should be a string (for DOM elements) or a ReactClass (for
composite components). Check the render method of AppContainer

Uncaught Invariant Violation: Element type is invalid:
expected a string (for built-in components) or a class/function (for
composite components) but got: object. Check the render method of
AppContainer.

I was able to reproduce the error in redmountainmakers/kilntroller-ui@985f14d by simply adding a line undefinedFunctionCall() to the code. No indication was given as to the real nature of the error - when it originally showed up, I had to downgrade to webpack v1 to diagnose and fix it in development mode.

Steps to reproduce:

git clone https://github.com/redmountainmakers/kilntroller-ui
cd kilntroller-ui/
git checkout webpack-2-error 
npm install
make run
# visit localhost:3000 and look at the console

Since there is a lot of code involved in making all this work, I'm not sure if this is the right repo to report this error against.

I'm not sure if this is related but it was also unexpected that one of my components' componentWillUnmount method was called without the corresponding componentDidMount being called first. In the commit I referenced above, I added some debugging statements to mark the methods in question.

[arcanis]

I also have this error. In order to have the actual error, I have to put a breakpoint on the following line:

return React.createElement(this.props.errorReporter, { error: error });

It seems that errorReporter is null for some reason, and we have to inspect the error variable manually.

[calesce]

This seems to be the same issue as #312, want to confirm this is fixed in 3.0.0-beta.3?

[nathanmarks]

@calesce One thing I noticed, I don't know if this is redbox related but I'm not getting sourcemapped stacktraces in redbox. When I switch to vanilla error handling (console, no redbox) I get stacktraces. Have you experienced this?

[calesce]

@nathanmarks Yeah, I'm seeing the same thing. I believe it should be handled by Redbox. Interestingly, on their README they recommend adding output.devtoolModuleFilenameTemplate to the webpack config and using devtool: 'eval'. I always used cheap-module-eval-source-map without many issues.

I also thought that the source maps worked for RHL3 Redbox previously, but maybe I'm mis-remembering.

[calesce]

@nathanmarks Ok, it looks like Redbox stack traces are only sourcemapped with devtool: eval, but then you lose source maps in browser devtools... I guess for now it's pick one or the other.

[nathanmarks]

@calesce That's a bit rubbish. How do you feel about removing redbox as the default error reporter and using the console instead?

[calesce]

@nathanmarks Yeah I'd like to see if there's a workaround first (or at the very least at least do console.log as well), but I'd probably agree.

[dreyks]

@calesce the issue is fixed in 3.0.0-beta.3

[calesce]

Thanks, @dreyks. @nylen / @arcanis, can you see whether it solved your issues?

[calesce]

@nathanmarks: We should probably move this to another thread, but I think Redbox will probably be best for now, even though it's not perfect.

Adding console reporting won't be any better, since the stack trace will still be bad with devtool: 'source-map', and the file context in the console will now come from AppContainer.dev.js instead of where the original error was thrown.

See error.stack in Chrome:

Also, I'm going to close this issue, since this was fixed in the latest beta.

[nylen]

Confirmed that upgrading react-hot-loader fixed the issue for me. Thanks for fixing it!