gatsby: TypeError: Data must be a string or a buffer

Gatsby v1.0.0
Node v7.5.0
MacOS v10.12.5

I produce the following error after a gatsby build:

crypto.js:74
  this._handle.update(data, encoding);
               ^

TypeError: Data must be a string or a buffer
    at Hash.update (crypto.js:74:16)
    at ~/Projects/victor/ubby-desktop/node_modules/gatsby/dist/utils/get-hash-fn.js:22:10
    at ~/Projects/victor/ubby-desktop/node_modules/gatsby/dist/utils/hashed-chunk-ids-plugin.js:20:22
    at Array.forEach (native)
    at Compilation.<anonymous> (~/Projects/victor/ubby-desktop/node_modules/gatsby/dist/utils/hashed-chunk-ids-plugin.js:18:14)
    at Compilation.applyPlugins (~/Projects/victor/ubby-desktop/node_modules/tapable/lib/Tapable.js:26:37)
    at Compilation.<anonymous> (~/Projects/victor/ubby-desktop/node_modules/webpack/lib/Compilation.js:545:8)
    at Compilation.applyPluginsAsync (~/Projects/victor/ubby-desktop/node_modules/tapable/lib/Tapable.js:60:69)
    at Compilation.seal (~/Projects/victor/ubby-desktop/node_modules/webpack/lib/Compilation.js:525:7)
    at Compiler.<anonymous> (~/Projects/victor/ubby-desktop/node_modules/webpack/lib/Compiler.js:397:15)
    at ~/Projects/victor/ubby-desktop/node_modules/tapable/lib/Tapable.js:103:11
    at Compilation.<anonymous> (~/Projects/victor/ubby-desktop/node_modules/webpack/lib/Compilation.js:445:10)
    at ~/Projects/victor/ubby-desktop/node_modules/webpack/lib/Compilation.js:417:12
    at ~/Projects/victor/ubby-desktop/node_modules/webpack/lib/Compilation.js:332:10
    at ~/Projects/victor/ubby-desktop/node_modules/webpack/node_modules/async/lib/async.js:52:16
    at done (~/Projects/victor/ubby-desktop/node_modules/webpack/node_modules/async/lib/async.js:246:17)
    at ~/Projects/victor/ubby-desktop/node_modules/webpack/node_modules/async/lib/async.js:44:16
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickCallback (internal/process/next_tick.js:98:9)

My package.json is:

{
  "name": "gatsby-starter-default",
  "description": "Gatsby default starter",
  "version": "1.0.0",
  "author": "Kyle Mathews <mathews.kyle@gmail.com>",
  "dependencies": {
    "fs": "0.0.1-security",
    "gatsby": "^1.4.1",
    "gatsby-link": "^1.4.1",
    "gatsby-plugin-sharp": "^1.0.0-beta.7",
    "gatsby-remark-copy-linked-files": "^1.0.0-beta.6",
    "gatsby-remark-images": "^1.5.0",
    "gatsby-remark-prismjs": "^1.0.0-beta.6",
    "gatsby-remark-responsive-iframe": "^1.0.0-beta.6",
    "gatsby-remark-smartypants": "^1.0.0-beta.6",
    "gatsby-source-filesystem": "^1.0.0-beta.6",
    "gatsby-transformer-remark": "^1.0.0-beta.6",
    "lodash": "^4.17.4",
    "object-assign": "^4.1.1",
    "react-helmet": "^5.0.3",
    "react-materialize": "^1.0.1",
    "react-typography": "^0.15.0",
    "typography": "^0.15.8",
    "typography-breakpoint-constants": "^0.14.0",
    "typography-plugin-code": "^0.15.9",
    "underscore.string": "^3.3.4"
  },
  "devDependencies": {
    "gh-pages": "^0.12.0"
  },
  "keywords": [
    "gatsby"
  ],
  "license": "MIT",
  "main": "n/a",
  "scripts": {
    "build": "gatsby build",
    "deploy": "gatsby build --prefix-links && gh-pages -d public",
    "develop": "gatsby develop",
    "format": "prettier --trailing-comma es5 --no-semi --single-quote --write \"pages/*.js\" \"utils/*.js\" \"wrappers/*.js\" \"html.js\"",
    "test": "echo \"Error: no test specified\" && exit 1"
  }
}

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 4
Comments: 28 (18 by maintainers)

Commits related to this issue

Demonstrating CSS Module import bug in Gatsby 1.3 Crashes with an error during `gatsby build`, as documented on gatsbyjs/gatsby#1659 — committed to digivizer/gatsby-1659 by maetl 7 years ago

Most upvoted comments

FYI @KyleAMathews and other @gatsbyjs maintainers, I’ve run into multiple problems relating to this issue as well, which I’ve documented in a test case repo here: https://github.com/digivizer/gatsby-1659

I’ve added notes to the README about how to reproduce the bug and differences in how it manifests between Gatsby 1.2 and 1.3+.

In the test case repo, there are two separate branches with different src/component trees and package.json dependencies that illustrate what’s happening:

Interestingly, the component tree in the 1.3 branch builds successfully with the 1.2 yarn.lock. However adding several more components with imported .module.sass files causes it to break in a related way.

These problems are not visible in gatsby develop. They only manifest when trying to build for production.

It’s also not immediately obvious whether this is a problem in Gatsby itself, or whether it is something to do with the underlying libraries and tools.

maetl on Aug 6, 2017

Same issue here. I’ve found that when several components from /src/pages/ import some shared component X

import X from './../shared/x';

and if the X component imports its css module

import styles from './x.module.css';

then this error occurs.

Also what’s really weird is that this happens in my project only when there are more than 3 such page components (importing X). For <= 3 it builds fine.

EDIT: Looks like this is indeed a problem with style imports. When a component imports styles and is itself being imported (even indirectly) several times this error occurs. In the end I had to switch to JSS.

0xc0dec on Jul 31, 2017

I have got the same issue, solved via third argument to require.ensure

require.ensure([], require => {
   require('./something');
}, 'name-of-my-chunk')

name-of-my-chunk will be explicitly assigned to dynamically loaded chunk.

However, of course it would be nice to make this working without this additional friction.

just-boris on Sep 8, 2017

So after many hours of debugging this for my site (which seemed to break out of nowhere, I assume because of dependencies that got updated after re-running yarn), I decided to start fresh from the blog starter site. I slowly added my site’s files into the newly created folder, building after each addition.

Turns out my specific issue was the use of require.ensure.

I’m not sure of the fix yet, but if that’s not everyone else’s issue, I’d recommend starting from scratch or something similar. I’ll report back here when I find a solution to this. I’d still like to lazy load modules if possible.

okcoker on Sep 8, 2017