Gatsby: Production Build on Netlify/Linux produce unhandled error

[3CordGuy]

This builds just fine locally both in gatsby develop and gatsby build.

But once it pulls from my git repo (and runs on Netlify), it throws this.

__Gatsby 1.1.10__

4:21:50 PM: success Building production JavaScript bundles — 13.303 s
4:21:55 PM: error UNHANDLED EXCEPTION
4:21:55 PM: 

  TypeError: errorStr.split is not a function

  - errors.js:41 createErrorFromString
    [repo]/[gatsby]/[gatsby-cli]/lib/reporter/errors.js:41:34

  - build-html.js:58 
    [repo]/[gatsby]/dist/commands/build-html.js:58:33

  - Compiler.js:194 Compiler.<anonymous>
    [repo]/[webpack]/lib/Compiler.js:194:14

  - Compiler.js:282 Compiler.emitRecords
    [repo]/[webpack]/lib/Compiler.js:282:37

  - Compiler.js:187 Compiler.<anonymous>
    [repo]/[webpack]/lib/Compiler.js:187:11

  - Compiler.js:275 
    [repo]/[webpack]/lib/Compiler.js:275:11

  - Tapable.js:60 Compiler.applyPluginsAsync
    [repo]/[tapable]/lib/Tapable.js:60:69

  - Compiler.js:272 Compiler.afterEmit
    [repo]/[webpack]/lib/Compiler.js:272:8

  - Compiler.js:267 Compiler.<anonymous>
    [repo]/[webpack]/lib/Compiler.js:267:14

  - async.js:52 
    [repo]/[webpack]/[async]/lib/async.js:52:16

  - async.js:246 done
    [repo]/[webpack]/[async]/lib/async.js:246:17

  - async.js:44 
    [repo]/[webpack]/[async]/lib/async.js:44:16

  - graceful-fs.js:43 
    [repo]/[graceful-fs]/graceful-fs.js:43:10

4:21:56 PM: Cached NPM modules

Is there any way I can dig into the actual unhandled error?

[KyleAMathews]

Hmmm looks like errorStr isn't set somehow https://github.com/gatsbyjs/gatsby/blob/2eb129ecf0ca07dea381327f1fc6ced190cd04d1/packages/gatsby-cli/src/reporter/errors.js#L44

Perhaps don't call that function from here before checking that the error array has something in it https://github.com/gatsbyjs/gatsby/blob/2eb129ecf0ca07dea381327f1fc6ced190cd04d1/packages/gatsby/src/commands/build-html.js#L35

[KyleAMathews]

To see the original error, add a console.log in build-html.js

Would appreciate a PR fixing up the error reporting.

[3CordGuy]

Sure I'll give it a shot.

[3CordGuy]

To see the original error, add a console.log in build-html.js

@KyleAMathews I'm a bit new to Netlify and CI patterns here. Do I need to create a forked build of gatsby and use that with the Netlify build process to test during the Netlify deploy (since that's where the error occurs)? Or am I missing something? I know you can download the Netlify build environment container, but I'm not sure if that's necessary...

I guess I don't know how to approach this since it only happens on Netlify's servers.

[KyleAMathews]

Yeah downloading Netlify's docker image could work or you could publish your forked version of Gatsby to NPM and use that.

[KyleAMathews]

Also it sounds like it's just a Linux issue so you could also try running the build process in a Linux VM.

[3CordGuy]

@KyleAMathews okay, Thanks for the feedback! I'll try to dive in some more.

[Unforgiven-wanda]

Suddenly started receiving this error after multiple successful builds.
Reverting several commits didn't help either, so I'm quite stumped.
Is there any progress on this?

[3CordGuy]

@Unforgiven-wanda I haven't had a chance to pull down the Netlify container and build against it locally to look at the error more in depth yet. Glad to know I'm not alone in this. I've also tried some quick fixes like reverting to specific versions of Gatsby.

[kylehotchkiss]

I am receiving this issue in 1.9.71 everytime there is a serverside-only bug on my mac (ie trying to access window.something). I'm having to edit the node_modules pretty consistently to get the console.log in there (everytime a package is added) to get the errors to print as expected.

So for me this isn't just netlfiy, it's yarn build in general

[KyleAMathews]

Add this PR which should help https://github.com/gatsbyjs/gatsby/pull/2537

Will merge and push soon.

[3CordGuy]

Bummer. Still throws for me... Anyone else have any luck?

3:39:47 PM: success Building production JavaScript bundles — 12.759 s
3:39:51 PM: error UNHANDLED EXCEPTION
3:39:51 PM: 
  TypeError: errorStr.split is not a function
  - errors.js:44 createErrorFromString
    [repo]/[gatsby-cli]/lib/reporter/errors.js:44:34
  - build-html.js:58 
    [repo]/[gatsby]/dist/commands/build-html.js:58:33
  - Compiler.js:194 Compiler.<anonymous>
    [repo]/[webpack]/lib/Compiler.js:194:14

. . .

[KyleAMathews]

Would love one of you to debug where this is happening. I can't do much more unless I have a way to reproduce what you're seeing.

[3CordGuy]

I will try to run the Netlify container tomorrow and see if I can debug. Didn’t have time today.

• Josh

On Oct 19, 2017, at 5:18 PM, Kyle Mathews [e-mail] wrote:

Would love one of you to debug where this is happening. I can't do much more unless I have a way to reproduce what you're seeing.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Repox]

I'm unsure if this is the actual error in this specific situation, but I found that in https://github.com/gatsbyjs/gatsby/blob/6fe44fe2e4d694a84f9a2339dd0eabc4106a44f5/packages/gatsby/src/commands/build-html.js#L35 the webpackErrros[0] contains an object and isn't a string by itself (which in turn causes split not being available on (what was expected to be a string) errorStr).

Instead, I tried appending .message to the object in build-html.js and I got error messages that could be understood again.

The line mentioned before, got changed to the following

return reject(createErrorFromString(webpackErrors[0].message, `${outputFile}.map`));

I'm not an experienced NodeJS developer, so someone might need to look more into if this is the actual issue - but it's definitely the issue here.

As others mentioned, this was only reproducible on a Linux box; trying to import a file in all lowercase didn't give problems locally, but Linux _does_ care, if the actual file is written in camel case (which was the given error in my situation).

[3CordGuy]

@Repox Thanks for posting this. Gave me insight on something to look for. I found a couple imports that had the improper case applied but didn't notice because I'm building locally on my mac.

Once I fixed them, the Netlify build went right through. 😃

I'm setting up a Linux VM right now to try and see what can be done about the error.

[3CordGuy]

After tinkering with my Linux VM. It definitely was the _Module not found_ error that was causing my initial pain.

That being said I noticed there was a PR #2360 that was merged recently that changed
let webpackErrors = stats.toJson().errors

to:

let webpackErrors = stats.compilation.errors.filter((e) => e)

I tried merely reverting this change back to the .toJson() approach and it does return the properly handled _Module not found_ error instead of the uncaught. But according to the PR mentioned earlier, this was added to filter out undefined elements in the array. Which I have no clue about, nor would I expect this to return any kind of array element except an Object to createErrorFromString.

I'm also pretty green when it comes to webpack, so I don't know a solid work around that still covers the bases of that previous PR #2360 besides converting the error object to a string prior to the promise rejection. Obviously createErrorFromString is expecting a string, but they are coming through as objects.

[Unforgiven-wanda]

Hello again,
in my particular case I managed to identify the issue by adding console.logs in the build-html.js as suggested by @KyleAMathews (I believe that a pull request to add console.warn there should be helpful, I wouldn't have found out the error otherwise)
The culprit was a package named react-scroll-to-component that was trying to require tween. Removing said package entirely fixed it for me.

[insanetisane]

I have this same error just running build on my local environment.

[nodox]

I just started getting this error today :( Are we close to a fix for this issue?

[danoc]

After console.loging in build-html:58, @evaughn and I are both seeing this error from Webpack:

[ { ModuleNotFoundError: Module not found: Error: Cannot resolve module 'xor' in <redacted>/www/node_modules/dom-iterator
      at <redacted>/www/node_modules/webpack/lib/Compilation.js:229:38
      at onDoneResolving (<redacted>/www/node_modules/webpack/lib/NormalModuleFactory.js:29:20)
      at <redacted>/www/node_modules/webpack/lib/NormalModuleFactory.js:85:20
      at <redacted>/www/node_modules/async/lib/async.js:726:13
      at <redacted>/www/node_modules/async/lib/async.js:52:16
      at done (<redacted>/www/node_modules/async/lib/async.js:241:17)
      at <redacted>/www/node_modules/async/lib/async.js:44:16
      at <redacted>/www/node_modules/async/lib/async.js:723:17
      at <redacted>/www/node_modules/async/lib/async.js:167:37
      at <redacted>/www/node_modules/enhanced-resolve/lib/UnsafeCachePlugin.js:24:19
      at onResolved (<redacted>/www/node_modules/enhanced-resolve/lib/Resolver.js:38:18)
      at innerCallback (<redacted>/www/node_modules/enhanced-resolve/lib/Resolver.js:94:11)
      at loggingCallbackWrapper (<redacted>/www/node_modules/enhanced-resolve/lib/createInnerCallback.js:21:19)
      at <redacted>/www/node_modules/tapable/lib/Tapable.js:134:6
      at <redacted>/www/node_modules/enhanced-resolve/lib/ModulesInDirectoriesPlugin.js:54:23
      at <redacted>/www/node_modules/enhanced-resolve/lib/Resolver.js:191:15
    name: 'ModuleNotFoundError',

I believe this traces back to https://github.com/matthewmueller/dom-iterator/issues/10.

[danoc]

A yarn why dom-iterator indicates that the package is getting pulled in from react-live. Are others also using react-live?

(Edit: We were able to fix the react-live issue with this helpful thread: https://github.com/FormidableLabs/react-live/issues/5)

That said, would be helpful to fix the error reporting so that the Webpack error is not hidden.

[ybbarng]

Hello, I am newbie to Gatsbyjs. I used gatsby-starter-lumen, on ubuntu 16.04 32bit with node v.8.8.1 and gatsby-cli version 1.1.11.
I've got the same error of this article while running 'gatsby build'.
The error says, TypeError errorStr.split is not a function at erros.js 44 at build-html.js
So I checked the webpackErrors object and stats.compilation.errors in build-html.js.
They had same characteristics:

1. They are a list which has length 2.
2. The type of first element is 'Error'. It says that .../node_modules/url/url.js?{"limit":10000,"name":"static/[name].[hash:8].[ext]"} didn't return a function.
3. The second one is a String. It says that `Error: Cannot find module "../../pages/photo.jpg" (but there is, .... but this is not the bug to report on this thread)

Well, it looks like there is an assumption that all the elements in stats.compiliation.errors are string or undefined, but because one of the element was an Error object, the assumption or any code which pushed the Error object is wrong.
Because the TypeError hides real errors, I think this must be fixed. I hope this comment is useful to find the bug.

[nodox]

I fixed this error on my machine. It seems I renamed a file incorrectly. Thus my conclusion is that it can be filesystem related.

[VitaliiZhukov]

Hi there!
Having the same issue.
What gatsby version is stable for it?

UPD
Finally I had to downgrade to gatsby 1.9.68 version

[robertgonzales]

Also having this issue. The build fails with errorStr.split and no way of finding the real error. Spent several hours trying to narrow down the error with no luck.

[3CordGuy]

@robertgonzales Did you try reverting the code that changed in #2360 back to what it was? When I did that my actual error was returned properly. See previous comment about that PR.

[KyleAMathews]

Would love someone from this thread to investigate the issue and create a PR!

[KyleAMathews]

Also helpful would be if someone has a public repo with this error you could share or if someone could build a site reproducing the problem. I don't know how to reproduce the problem you're seeing so can't solve it.

[3CordGuy]

@KyleAMathews Just created this fork https://github.com/3CordGuy/gatsby-starter-default
which adds a component with a bad camel cased path that will throw an error on linux. It's producing the aforementioned results on Netlify for me. Most of what people are reporting here are filesystem related.... I did notice just now that the Linux build says the following prior to installation:

2:10:09 PM: warning [email protected]: The platform "linux" is incompatible with this module.

2:10:09 PM: info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.

So I'm not sure if that is related to the bad error parsing from the Webpack errors array where the problem actually surfaces.

[KyleAMathews]

@3CordGuy want to try @jquense's PR? https://github.com/gatsbyjs/gatsby/pull/2697

[3CordGuy]

Oh Cool. Minus the added .filter method, that is the same thing I did last week to get the error to report properly.

[KyleAMathews]

@3CordGuy cool!

Hey everyone that's hit this — just published @jquense's fix to NPM — let us know if this fixes things for you!

[3CordGuy]

@KyleAMathews

Just ran the new version against the Netlify repo I created and it reports the error just fine now. 👍

See our docs page on debugging HTML builds for help https://goo.gl/yL9lND
2:39:05 PM: 

  Error: Module not found: Error: Cannot resolve 'file' or 'directory' ../compon  ents/Thing in /opt/build/repo/src/pages
  resolve file
    /opt/build/repo/src/components/Thing doesn't exist
    /opt/build/repo/src/components/Thing.js doesn't exist
    /opt/build/repo/src/components/Thing.jsx doesn't exist
  resolve directory
    /opt/build/repo/src/components/Thing doesn't exist (directory default file)
    /opt/build/repo/src/components/Thing/package.json doesn't exist (directory d  escription file)
  [/opt/build/repo/src/components/Thing]
  [/opt/build/repo/src/components/Thing.js]
  [/opt/build/repo/src/components/Thing.jsx]
   @ ./src/pages/index.js 13:13-43

[3CordGuy]

@VitaliiZhukov You should be good with ^1.9.86 for this issue now.

[robertgonzales]

Latest release reports the error correctly. Looks like it was the Linux case-sensitive module name issue mentioned above. Thanks @KyleAMathews @jquense so much for the quick turnaround!

[3CordGuy]

Sounds like this issue can be closed.