[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?