[1.0] Typeface produces error in production build

[0x80]

I'm importing a typeface package in my default layout. It works in development. In production the font also loads, but produces the following error.

bootstrap b3d99bd…:52 Uncaught TypeError: Cannot read property 'call' of undefined
    at t (bootstrap b3d99bd…:52)
    at Object../node_modules/typeface-roboto/index.css (index.css:1)
    at t (bootstrap b3d99bd…:52)
    at Object../node_modules/babel-loader/lib/index.js?{"presets":["/Users/me/project/node_modules/babel-preset-env/lib/index.js","/Users/me/project/node_modules/babel-preset-react/lib/index.js","/Users/me/project/node_modules/babel-preset-stage-1/lib/index.js","/Users/me/project/node_modules/babel-preset-es2015/lib/index.js","/Users/me/project/node_modules/babel-preset-stage-0/lib/index.js","/Users/me/project/node_modules/babel-preset-react/lib/index.js"],"env":{"development":{"plugins":["add-module-exports","flow-react-proptypes",["styled-components",{"minify":false,"displayName":true}]]},"production":{"plugins":["add-module-exports","flow-react-proptypes",["styled-components",{"ssr":true,"displayName":false}]]}},"plugins":["/Users/me/project/node_modules/gatsby/dist/utils/babel-plugin-extract-graphql.js","/Users/me/project/node_modules/babel-plugin-add-module-exports/lib/index.js","/Users/me/project/node_modules/babel-plugin-add-module-exports/lib/index.js","/Users/me/project/node_modules/babel-plugin-transform-object-assign/lib/index.js"],"cacheDirectory":true}!./src/layouts/index.js (index.js:10)
    at t (bootstrap b3d99bd…:52)
    at index.js?9a34:3
    at window.webpackJsonp (bootstrap b3d99bd…:20)
    at layout-component---index-b4f03b0….js:1

It points to this line in bootstrap

// Execute the module function
modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);

And further down

exports = module.exports = require("../css-loader/lib/css-base.js")();

in index.css

I didn't change anything to the webpack configuration regarding css. Any idea what might cause this?

[KyleAMathews]

No idea what's happening... can you reproduce this on another site?

[0x80]

I've tried gatsbygram but can't seem to reproduce it. Copying the typeface module files to my src files and including the css directly from my code fixes the problem. I'll use that as a workaround until I am able to investigate further...

[scottyeck]

We are just now observing this error as well in v1.0.0-alpha15-alpha.330d917d, though the cause has nothing to do with a typeface dependency import, as we're doing no such thing.

[miracle2k]

I had this. As much as I could figure out, it happens whenever I import the layout/index.js file by myself from somewhere (rather than letting only gatsby do it). It seems to screw up the webpack splitting, which then means that ../css-loader/lib/css-base.js is not available.

[octalmage]

I'm running into this issue now here:

https://jason.stallin.gs

It happens occasionally when you navigate between pages. I can't reliably reproduce it, but when it happens the navigation fails. Then sometimes you can click the link again and it will work, sometimes you have to refresh the page.

The source code is here, trying to debug it and figure it out: https://github.com/octalmage/jason.stallin.gs

[ajorkowski]

Hi,

I'm actually getting this same issue, its strange as it seems to come up only on (some?) production builds. It looks like the error is happening on this line in webpack bootstrap:

modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);

In my case the moduleId is 329, and I can see that the modules does not have that value, thus the null exception.

I did some investigating, and I think I may have a reason, but I have no idea what is causing it yet... If I look at my built path---index-*.js file I see that it is defining a module with id 325:

path---index-a0e39f21c11f6a62c5ab.js

webpackJsonp([0x81b8806e4260],{325:function(t,e){t.exports={pathContext:{}}}});
//# sourceMappingURL=path---index-a0e39f21c11f6a62c5ab.js.map

Looking at the app-*.js bundle, I can find the corresponding mapping there (I matched on that hash value). In this case it seems to be trying to load module 329 for that page:

app-bc4b6baa4911562f087f.js

...
function(n){return t.e(0x81b8806e4260,function(e,o){o?(console.log("bundle loading error",o),n(!0)):n(null,function(){return t(329)})}
...

Interestingly, if I look at the 'mapped' js code I see that it thinks the 325 value is actually 329 :

path---index-a0e39f21c11f6a62c5ab.js (mapped)

webpackJsonp([142629428675168],{

/***/ 329:
/***/ (function(module, exports) {

	module.exports = {"pathContext":{}}

/***/ })

});


// WEBPACK FOOTER //
// path---index-a0e39f21c11f6a62c5ab.js

So it looks like there is something happened to the output of the page file after it creates the .map file, but before the final output is complete... I guess?

In my case, the page is shows up because of the initial server side render, but the js is unable to run at all. It seems I get the module mismatch issues on a number of pages in my production build.

[ajorkowski]

Interestingly, If I run the build locally (via gatsby build) I get a path---index-a0e39f21c11f6a62c5ab.js/path---index-a0e39f21c11f6a62c5ab.js.map file which is correct BUT the actual moduleId is different - they are both showing 393 as the module id.

This might be a possible cause to the issue? Why is the file hash the same when the actual content is different? Actually... We are using cloudflare to do caching, so yup, as soon as I cleared the cache our pages are working again (after a hard-cache-refresh).

For whatever reason, if I delete the public folder and rebuild it, I am still getting 393 as the module id, so it does look like it is somewhat deterministic. I develop locally on windows but my build server is linux. I'm not sure why different builds on my build box would cause different module ids however... I DID just update my gatsby version to latest - perhaps that caused some sort of reordering or something?

So to summarize - the problem occurs during deployment - as the internal module ids are changing (sometimes) even though the hash of the page is staying the same. This would obviously cause havoc with client-side caching etc.

[ajorkowski]

Looks like the fix might involve fixing up the module/chunk plugins that are being used?

// new WebpackStableModuleIdAndHash({ seed: 9, hashSize: 47 }),
new HashedChunkIdsPlugin()

Looking at the implementation of the HashedChunkIdsPlugin - it is generating the id from the hash of the name of the module, however for async chunks the name is actually undefined, so I think in those cases it falls back to using a numbered id.

I am using this combination of ModuleId/Chunks plugins in another project to get consistent module/chunk naming, based of the content of their respective pieces:

  new webpack.HashedModuleIdsPlugin(), // Create module ids that are based on the content of the module
  new webpack.NamedChunksPlugin((chunk) => {
    if (chunk.name) { return chunk.name; }

    // If we don't have a chunk name, generate one by hashing all the module ids
    // We need this as chunks generated from async splits has no chunk.name
    const hash = createHash("md5");
    hash.update(chunk.mapModules(m => m.id).join("_")); // Create the id from the combination of the module ids
    const hashId = hash.digest('hex');
    let len = 4;
    while(usedIds.has(hashId.substr(0, len))) len++;
    var newId = hashId.substr(0, len);
    usedIds.add(newId);
    return "a" + newId;
  })

This way, when a single module changes, it will have a consistent module id (regardless of order/environment/etc) and any chunks that include that id will also change consistently, even if they are being created from async code split.

Saying that - I'm not 100% sure this would fix the issue, because for some reason the chunkhash was the same even though the content was different (ie the module id). I don't really see how this could have happened... Apparently once upon a time webpack chunkhash was not deterministic, but it should be now. Maybe need to use something like webpack-md5-hash to force it?

[octalmage]

I believe I might have fixed it with this commit:

octalmage/jason.stallin.gs@28cd2a7

Still testing it though.

[ptolemybarnes]

I'm also having this issue between 2 versions of an application:

I have a file path---page-name-a254b551b9a36f0acdb9.js in both versions, which differ only in the first couple of lines:

v.1.1

webpackJsonp([0x5d81803451ed], {
    684: function(e, t) {
        e.exports = {
// ... etc

v.1.0

webpackJsonp([0x5d81803451ed], {
    "../../node_modules/json-loader/index.js!./.cache/json/page-name.json": function(e, t) {
        e.exports = {
// ... etc

[drewdrewthis]

What was the resolution to this problem? We're also having this problem -- not related to Bootstrap tho. Seems like the webpackJsonp referencing the wrong hashed js file.

[baba43]

Today I have encountered the same issue and can not get it to work.

Do you guys have any updates on this?

[erquhart]

Possible fix in #3652, please test if you're still having this issue.

[edude03]

I've upgraded to Gatsby 1.9.178 and I'm still having this issue.

[andvgal]

I can confirm the problem on 1.9.173, but it got vanished with update to 1.9.186 (perhaps some other dep version change).

It was not reproducible on desktop, but hard reproducible in mobile Chrome with react router Redirect, like:

import React from 'react'

import { Redirect } from 'react-router'

const Landing = () => (
  <Redirect to="/docs/" />
)

export default Landing

It looks like some sort of race condition. However, I am not completely sure if the problem is really fixed, but not just hidden.

[edude03]

@andvgal Thanks for the update, you're right! Updated gatsby and my site is working.

[jeffwillette]

I had the error on 1.9.158 and I just updated to 1.9.199 and I still have the error.

[stinodes]

Ran into the same issue, I was on version 1.9.202.
Downgrading to 1.9.199 fixed it.

Edit: I spoke to soon. A second run through CI resulted int the same error.

[russellschmidt]

Having this problem on 1.9.222 and as with others only in production (hosted on Github Pages). Clicking a Link (as opposed to an a tag) throws the error and does not work. You can still navigate to other pages by keying in the path into a browser. Downgrading to 1.1.199 did not fix.

Uncaught TypeError: Cannot read property 'call' of undefined
    at t (bootstrap 7453813e23bfc7dfdf6a:52)
    at portfolio.json?c365:9
    at loader.js:116
    at loader.js:97
    at portfolio.json?c365:9
    at i (patch.js:19)
    at patch.js:40
    at window.webpackJsonp (bootstrap 7453813e23bfc7dfdf6a:20)
    at VM880 path---portfolio-70b1f4b3fe458d5e7bba.js:1

[russellschmidt]

Update: deployed my portfolio test site to Netlify. No errors.
https://github.com/russellschmidt/russellschmidt.github.io on github pages is http://russellschmidt.github.io and https://github.com/russellschmidt/rs-blog-3 which was formerly my dev repo is now prod for http://rusl.io. Maybe there is a race condition that only comes out when Github is hammered by DDOS all day today?

**** Update: site started working on Github this the following morning, error has disappeared.

[stefanwille]

Same issue here

[kmjennison]

I ran into this, and the root problem was that I was caching JS files, which Gatsby v1 doesn't support. See #2538 and docs on caching.

The problem's fixed since we made sure our CDN doesn't cache JS.

[jeffwillette]

I just briefly ran into this problem again, and it had to do with caching for me too. I was doing a local test of a prod build and using serve -s public/ which enables caching. Serving with serve public/ and doing a hard refresh fixed the problem

[kakadiadarpan]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub issues, we have to clean some of the old issues as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Gatsby version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[kakadiadarpan]

This issue is being closed because there hasn't been any activity for at least 30 days. Feel free to open a new one if you still experience this problem 👍