Gatsby: Develop works, build fails: Cannot read property 'initial' of undefined

[rshah03]

My develop version runs fine, with no issues. However, I get the following error(s) when I run gatsby build or any sort of production script:

/home/coder/Developer/portfolio/node_modules/extract-text-webpack-plugin/index.js:22
            if(c.initial) return;
                ^

TypeError: Cannot read property 'initial' of undefined
    at ExtractTextPlugin.<anonymous> (/home/coder/Developer/portfolio/node_modules/extract-text-webpack-plugin/index.js:22:8)
    at Array.forEach (native)
    at ExtractTextPlugin.mergeNonInitialChunks (/home/coder/Developer/portfolio/node_modules/extract-text-webpack-plugin/index.js:21:16)
    at ExtractTextPlugin.<anonymous> (/home/coder/Developer/portfolio/node_modules/extract-text-webpack-plugin/index.js:275:12)
    at Array.forEach (native)
    at ExtractTextPlugin.<anonymous> (/home/coder/Developer/portfolio/node_modules/extract-text-webpack-plugin/index.js:273:21)
    at /home/coder/Developer/portfolio/node_modules/extract-text-webpack-plugin/node_modules/async/lib/async.js:52:16
    at Object.async.forEachOf.async.eachOf (/home/coder/Developer/portfolio/node_modules/extract-text-webpack-plugin/node_modules/async/lib/async.js:236:30)
    at Object.async.forEach.async.each (/home/coder/Developer/portfolio/node_modules/extract-text-webpack-plugin/node_modules/async/lib/async.js:209:22)
    at ExtractTextPlugin.<anonymous> (/home/coder/Developer/portfolio/node_modules/extract-text-webpack-plugin/index.js:237:10)
    at Compilation.applyPluginsAsync (/home/coder/Developer/portfolio/node_modules/tapable/lib/Tapable.js:71:13)
    at Compilation.seal (/home/coder/Developer/portfolio/node_modules/webpack/lib/Compilation.js:525:7)
    at Compiler.<anonymous> (/home/coder/Developer/portfolio/node_modules/webpack/lib/Compiler.js:397:15)
    at /home/coder/Developer/portfolio/node_modules/tapable/lib/Tapable.js:103:11
    at Compilation.<anonymous> (/home/coder/Developer/portfolio/node_modules/webpack/lib/Compilation.js:445:10)
    at /home/coder/Developer/portfolio/node_modules/webpack/lib/Compilation.js:417:12

I have absolutely no idea what the root of this problem is. Any help would be appreciated.

[rshah03]

Fix: Add if (typeof c === 'undefined') return; right below line 21 in node_modules/extract-text-webpack-plugin/index.js

[just-boris]

I could reproduce the same problem. It is somehow related to the number of pages that you have.
There is a sample project, where you can look at it: https://github.com/just-boris/gatsby-issue-1846

I have created a file src/pages/AbstractPage.js and three src/pages/ChildPage-N.js files, which are depending from AbstractPage. When you run npm run build, you will see the expected error

error UNHANDLED EXCEPTION
  TypeError: Cannot read property 'initial' of undefined
  - index.js:23 ExtractTextPlugin.<anonymous>
    [test]/[extract-text-webpack-plugin]/index.js:23:8

Also, I would like to mention, that there is an issue https://github.com/webpack-contrib/extract-text-webpack-plugin/issues/115 which says that CommonsChunkPlugin somehow screws up the build under some conditions.

[just-boris]

@rshah03 could you please re-open the issue? The solution of editing files in node_modules is not acceptable, because people usually do not modify third-party-dependencies directly.

[rshah03]

@just-boris Thanks! Re-opened the issue. Yeah, I was trying to find other possible solutions, but wasn't able to. Thought I would stick with that temp fix for the time being. I will take a look at your sample project and likely redo my project with fewer pages/components.

[azoff]

My workaround, fwiw, in my package.json file:

{ ...
    "scripts": {
        "patch": "sed -i -e 's/if(c\\.initial) return;/if(!c||c.initial) return;/g' ./node_modules/extract-text-webpack-plugin/index.js",
        "build": "npm run patch && gatsby build",
    }
...
}

[nickguletskii]

This seems to be caused by Webpack's RemoveEmptyChunksPlugin and how Webpack removes chunks. Before applying ExtractTextWebpackPlugin, Webpack runs RemoveEmptyChunksPlugin which can remove component chunks from Webpack's chunk list. The problem is that it doesn't remove the empty chunk from the chunk called app, and when ExtractTextWebpackPlugin is called it tries to look up a chunk that doesn't exist. Since there is no consistency check there, extractedChunks[chunks.indexOf(c)] returns undefined and undefined gets added to the list of chunks.

I am not sure where I should report this, and what is the best workaround at the moment.

[fkoner]

Have you checked the following link:

https://github.com/webpack-contrib/extract-text-webpack-plugin/pull/170

https://github.com/webpack/webpack/commit/79eb40425715cf7759b01a7a32b9c85d79c88e96

Applying @azoff workaround gives the following error:

````
error Generating static HTML for pages failed

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

Error:
Error: Module not found: Error: Cannot resolve 'file' or 'directory' ../public/chunk-manifest.json in /opt/ development/github-projects/dentegra/static-cus tomer-website/.cache
resolve file
/opt/development/github-projects/dentegra/static-customer-website/public/chunk-manifest.json doesn't exist
/opt/development/github-projects/dentegra/static-customer-website/public/chunk-manifest.json.js doesn't exist
/opt/development/github-projects/dentegra/static-customer-website/public/chunk-manifest.json.jsx doesn't exist
resolve directory
/opt/development/github-projects/dentegra/static-customer-website/public/chunk-manifest.json doesn't exist (directory default file)
/opt/development/github-projects/dentegra/static-customer-website/public/chunk-manifest.json/package.json doesn't exist (directory descri ption file)
[/opt/development/github-projects/dentegra/static-customer-website/public/chunk-manifest.json]
[/opt/development/github-projects/dentegra/static-customer-website/public/chunk-manifest.json.js]
[/opt/development/github-projects/dentegra/static-customer-website/public/chunk-manifest.json.jsx]
@ ./.cache/static-entry.js 143:22-67

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: npm run patch && gatsby build
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! /Users/Carlos/.npm/_logs/2017-09-04T03_52_39_891Z-debug.log
````
Related to https://github.com/gatsbyjs/gatsby/issues/1850

It seems the version of webpack and extract-text-webpack-plugin is too old in gatsby.

[nickguletskii]

I guess this bug will have to wait for Gatsby 2 (#1824), since I don't think Webpack devs will be interested in bug reports for Webpack 1. I am pretty sure that the bug still exists in Webpack 3, but I currently don't have the time to create a minimal example. Maybe someone else could take a Webpack 3 config and try to replicate as follows:

1. Create a file we will call shared, tell Webpack to make a chunk for it (or however that works, I am not sure).
2. Create a lot of files that import shared and have Webpack make chunks for them.
3. Create a chunk that depends on all chunks.
4. Make sure that the shared chunk is being deleted by RemoveEmptyChunksPlugin.
5. Check if the chunk that depends on all chunks still references the shared chunk. If it does, then the bug is not fixed in Webpack 3.

I worked around this bug by eliminating inter-page imports. I had a lot of pages import stuff from an index page and that was causing the index page to become an empty chunk (my guess is that it was being inlined into other chunks).

[fkoner]

@nickguletskii
So it is advisable not to nest pages, or at least not concentrate all the pages inside a main.

What was the process you followed?

With this procedure you avoid the workaround of @azoff and also the error https://github.com/gatsbyjs/gatsby/issues/1850?

[nickguletskii]

My process involved moving common logic and data into a file outside the pages directory. I had a system for getting metadata from parent pages, which I had to replace with a centralised metadata store. I never had issue #1850, but my workaround is not related to @azoff's in any way.

[c2pig]

upgrade to latest version "gatsby": "^1.9.23", i dont see the error anymore.

[canoqb10]

I have upgraded to latest version and I continue with same issue

[Ayorinde]

Works fine when I don't have gatsby develop running.

[revolunet]

hitting the same issue here but with ~100 markdown files and 5 templates... any idea how to solve this ?

[canoqb10]

Yes @revolunet you should not have pages or components that are called within other pages within the folder of pages, that is, inside the folder of pages you must only have the pages that are functional for gatsby, if any of those pages needs some components you must position them outside of the page folder, this resolve the issue for me

[revolunet]

in my case i have nothing in /pages except 404.js , just a lot of markdown in /content and 5 templates in /templates

[revolunet]

after a fun hunt, i found a hacky workaround, but i cant understand why it solves the issue

In src/templates, i had 9 templates using src/templates/page.js and had the "initial" bug on build, but for some reason, extracting page.js to "src/page.js" solved the issue.

so as @canoqb10 mentions, one shouldn't put reusable components inside templates or pages

[revolunet]

Stumbled upon the same error, triggered from that buggy code :

 const onRef = {
    log404();
  };
  return (
    <Page
      ref={onRef}

the onRef should be a function.

 const onRef = () => {
    log404();
  };

BTW, this trigger via webpack the infamous "Cannot read property 'initial' of undefined".

The issue source is the user code itself, but the error come from https://github.com/webpack-contrib/extract-text-webpack-plugin, just submitted a PR for webpack 1 users

[neilyoung]

@rshah03 In fact your answer from August it the only right answer, if you do the same alt line 23 also

[adrienharnay]

Bump, stumbling on this also. Tried the patch from https://github.com/gatsbyjs/gatsby/issues/1846#issuecomment-324744367, but got the error from https://github.com/gatsbyjs/gatsby/issues/1846#issuecomment-326858100

[rshah03]

@neilyoung Though that works, it's generally bad practice to modify files within the node_modules directory, so it's not an ideal fix. I guess it would be okay for development, but probably not a good idea for production.

@Zephir77167 I ended up creating a new iteration of my project without nesting components within each other. This worked fine and the issue didn't come up again. I think Gatsby can handle 1 layer of directly embedded components, but no more.

[adrienharnay]

Yeah I guess so, I moved all the components in pages to another folder (src/views), and then imported the root component in each page. That solved it for me

[BipinBhandari]

To me, this issue occurred when I imported constant in one page from another page.
Fixed by moving constant to utilities folder and importing from there.

[ntnbst]

Did anyone find the fix of this issue??
Other than modifying the node modules files .

[philippefutureboy]

If that can help anyone out there, I encountered this error because a component under layouts was referencing a page under page. Moving the page to layouts solved the problem.

@KyleAMathews Could this be in the docs, in shiny flashing bold?

[KyleAMathews]

v2 is out which upgrades webpack and plugins + removes the confusing layouts component so closing. See the v2 migration guide to upgrade! https://next.gatsbyjs.org/docs/migrating-from-v1-to-v2/

[alexlouden]

I hit this issue too - I added the workaround to node_modules/gatsby-1-config-extract-plugin/node_modules/extract-text-webpack-plugin, and then when I re-ran gatsby build the actual error showed up. There was a syntax error in my page template - I was assigning to a const. Just a heads up - for me this error was masking the syntax error, so when I fixed the syntax error I could remove the workaround and the build succeeded.

[Jvalal]

I'm still getting this error. I tried adding the patch from 1846, but no dice.