Javascript heap out of memory when doing build-storybook

[yuanstanley]

Describe the bug When trying to do build-storybook it gets to 92% and then fails with the following out of memory error:

92% chunk asset optimization TerserPlugin
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 00007FF7CF93EEE5 
 2: 00007FF7CF918CD6 
 3: 00007FF7CF9196E0 
 4: 00007FF7CFD80D3E 
 5: 00007FF7CFD80C6F 
 6: 00007FF7CFCCC594 
 7: 00007FF7CFCC2B67 
 8: 00007FF7CFCC10DC 
 9: 00007FF7CFCCA0B7 
10: 00007FF7CFCCA136 
11: 00007FF7CFDEF7B7 
12: 00007FF7CFEC87FA 
13: 000000D1798DC6C1 
error Command failed with exit code 134.

The entirety of my source code is less than 1 MB so not sure why I would be OOM.

To Reproduce Steps to reproduce the behavior:

Run yarn build-storybook

Expected behavior The build shouldn't fail.

Screenshots If applicable, add screenshots to help explain your problem.

Code snippets

My current webpack.config.js

const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
    optimization: {
        // This line added as an earlier solution to this OOM error
        minimizer: [new TerserPlugin({ parallel: false })],
      },
    resolve: {
        extensions: ['.ts', '.tsx']
    },
    module: {
        rules: [{
            test: /\.js$/,
            use: 'source-map-loader',
            exclude: /node_modules/,
            enforce: 'pre'
          },
          {
            test: /\.tsx?$/,
            use: 'ts-loader',
            exclude: /node_modules/
          },
          {
            test: /\.scss$/,
            use: [{
                loader: "style-loader"
            }, {
                loader: "css-loader", options: {
                    sourceMap: true
                }
            }, {
                loader: "sass-loader", options: {
                    sourceMap: true
                }
            }]
          },
          {
            test: /\.stories\.tsx?$/,
            loaders: [{
                loader: require.resolve('@storybook/addon-storysource/loader'),
                options: {
                    parser: 'typescript'
                }
            }],
            enforce: 'pre',
        }
        ]
      }
}

My current .storybook config.js

import { addDecorator, configure } from '@storybook/react';
import { withOptions } from '@storybook/addon-options';
import { withKnobs } from '@storybook/addon-knobs';

// add withKnobs
addDecorator(withKnobs);

// Option defaults:
// Full settings here: https://github.com/storybooks/storybook/tree/master/addons/options
addDecorator(
  withOptions({
    name: 'some-package Storybook',
    showAddonPanel: false,
    addonPanelInRight: true,
    showStoriesPanel: false,
    sortStoriesByKind: true
  })
);

function loadStories() {
  const req = require.context('../src/', true, /\.stories\.tsx?$/)
  req.keys().forEach((filename) => req(filename))
}
configure(loadStories, module);

I also tried changing the build-storybook command in my package.json to force increase the memory, but that doesn't seem to work either. "build-storybook": "npx --max_old_space_size=16384 build-storybook"

My full package.json

{
  "name": "some-package",
  "version": "0.0.1",
  "description": "PackageDescription",
  "registry": "https://myurl.com/",
  "main": "dist/charts.js",
  "types": "dist/charts.d.ts",
  "license": "ISC",
  "engines": {
    "node": ">=8.*",
    "yarn": ">=1.*"
  },
  "scripts": {
    "auth": "npx vsts-npm-auth -config .npmrc",
    "dev": "webpack --mode=development",
    "dev:watch": "webpack --mode=development --watch",
    "build": "webpack --mode=production",
    "lint": "tslint ./src/**/*.{ts,tsx}",
    "fix_coverage": "node ./fix_coverage.js",
    "test": "yarn lint && jest --coverage",
    "test:watch": "yarn lint && jest --watch",
    "test:watchAll": "yarn lint && jest --watchAll",
    "storybook": "start-storybook -p 6006",
    "build-storybook": "npx --max_old_space_size=16384 build-storybook"
  },
  "dependencies": {
    "json5": "^2.1.0",
    "lodash": "4.17.11",
    "moment": "^2.24.0",
    "react-localization": "^1.0.13",
    "react-select": "^2.3.0",
    "react-split-pane": "0.1.77",
    "sinon": "^7.2.3",
    "ts-mock-imports": "^1.2.2"
  },
  "peerDependencies": {
    "office-ui-fabric-react": "6.*",
    "plotly.js": "1.*",
    "react": "16.*",
    "react-dom": "16.*",
    "react-localization": "^1.0.13",
    "react-plotly.js": "2.*",
    "uuid": "^3.3.2"
  },
  "devDependencies": {
    "@babel/core": "7.1.6",
    "@storybook/addon-knobs": "4.1.16",
    "@storybook/addon-options": "4.1.16",
    "@storybook/addon-storysource": "4.1.16",
    "@storybook/react": "4.1.16",
    "@types/enzyme": "^3.1.15",
    "@types/jest": "^23.3.10",
    "@types/lodash": "4.14.118",
    "@types/plotly.js": "1.41.0",
    "@types/react": "16.7.9",
    "@types/react-dom": "16.0.11",
    "@types/react-plotly.js": "2.2.2",
    "@types/react-select": "^2.0.11",
    "@types/storybook__addon-knobs": "4.0.4",
    "@types/storybook__react": "4.0.1",
    "@types/uuid": "^3.4.4",
    "babel-loader": "8.0.4",
    "clean-webpack-plugin": "1.0.0",
    "css-loader": "^2.1.0",
    "dts-bundle-webpack": "1.0.1",
    "enzyme": "^3.8.0",
    "enzyme-adapter-react-16": "^1.7.1",
    "enzyme-to-json": "^3.3.5",
    "fork-ts-checker-webpack-plugin": "0.5.0",
    "fs-jetpack": "2.2.0",
    "gulp-jest": "^4.0.2",
    "identity-obj-proxy": "^3.0.0",
    "inline-css": "2.4.1",
    "jest": "^23.6.0",
    "jest-canvas-mock": "^1.1.0",
    "jest-cli": "^24.1.0",
    "jest-junit": "5.2.0",
    "net": "^1.0.2",
    "node-sass": "^4.11.0",
    "office-ui-fabric-react": "6.158.0",
    "plotly.js": "^1.44.4",
    "react": "16.6.3",
    "react-dom": "16.6.3",
    "react-plotly.js": "2.2.0",
    "sass-loader": "^7.1.0",
    "source-map-loader": "0.2.4",
    "style-loader": "^0.23.1",
    "terser-webpack-plugin": "^1.2.3",
    "tls": "^0.0.1",
    "ts-jest": "23.10.5",
    "ts-loader": "5.3.1",
    "tslint": "5.11.0",
    "tslint-config-prettier": "1.17.0",
    "tslint-react": "3.6.0",
    "typescript": "3.2.1",
    "webpack": "4.29.6",
    "webpack-cli": "3.3.0"
  }
}

System:

• OS: Windows 10
• Device: HP Desktop
• Browser: Chrome
• Framework: React
• Addons: @storybook/addon-knobs, @storybook/addon-options, @storybook/addon-storysource
• Version: 4.1.16

[yuanstanley]

This issue ended up being resolved when I upgraded to the latest storybook version, 5.0.6.

[shilman]

Thanks for following up @yuanstanley -- glad it's working for you!

[Tobi-mmt]

I want to reopen this issue

Describe the bug I got the exact same issue like @yuanstanley in version 5.3.13 of storybook. Updateing to the newest version does not help. So it's really the same issue. The build-storybook command stops at 92% while doing stuff in the TerserPlugin.

thre strange part for me is, that the build run previous without problems. But from one day to the next it does not work anymore. My collegues run on the same OS, the exact same version of storybook (same package lockfile) but do not run into the issue.

Here the full error:

yarn run v1.22.4
$ build-storybook
info @storybook/react v5.3.13
info 
info clean outputDir..
info => Copying prebuild dll's..
info => Building manager..
info => Loading manager config..
info => Loading presets
info => Loading custom manager config.
info => Compiling manager..
info => manager built (6.35 s)
info => Building preview..
info => Loading preview config..
info => Loading presets
info => Loading config/preview file in ".storybook".
info => Loading custom Webpack config (full-control mode).
info => Using base config because react-scripts is not installed.
info => Compiling preview..
92% chunk asset optimization TerserPluginFATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x100d77bad node::Abort() (.cold.1) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 2: 0x10003ae83 node_module_register [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 3: 0x10003b044 node::FatalTryCatch::~FatalTryCatch() [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 4: 0x1001aa117 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 5: 0x1001aa0b1 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 6: 0x1005994c2 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 7: 0x10059bbf3 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 8: 0x100597b6e v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 9: 0x1005959ed v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
10: 0x1005a2c15 v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
11: 0x1005a2c7f v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
12: 0x100571e63 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
13: 0x100805ccc v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
14: 0x2959cc1dbe3d 
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x100d77bad node::Abort() (.cold.1) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 2: 0x10003ae83 node_module_register [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 3: 0x10003b044 node::FatalTryCatch::~FatalTryCatch() [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 4: 0x1001aa117 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 5: 0x1001aa0b1 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 6: 0x1005994c2 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 7: 0x10059bbf3 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 8: 0x100597b6e v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 9: 0x1005959ed v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
10: 0x1005a2c15 v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
11: 0x1005a2c7f v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
12: 0x100571e63 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
13: 0x100805ccc v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
14: 0xca95225be3d 
15: 0xca95225d1ff 
^[[1;2DFATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x100d77bad node::Abort() (.cold.1) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 2: 0x10003ae83 node_module_register [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 3: 0x10003b044 node::FatalTryCatch::~FatalTryCatch() [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 4: 0x1001aa117 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 5: 0x1001aa0b1 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 6: 0x1005994c2 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 7: 0x10059bbf3 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 8: 0x100597b6e v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 9: 0x1005959ed v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
10: 0x1005a2c15 v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
11: 0x1005a2c7f v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
12: 0x100571e63 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
13: 0x100805ccc v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
14: 0x1e9b8b8dbe3d 
15: 0x1e9b8b8dd1ff 
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x100d77bad node::Abort() (.cold.1) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 2: 0x10003ae83 node_module_register [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 3: 0x10003b044 node::FatalTryCatch::~FatalTryCatch() [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 4: 0x1001aa117 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 5: 0x1001aa0b1 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 6: 0x1005994c2 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 7: 0x10059bbf3 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 8: 0x100597b6e v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
 9: 0x1005959ed v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
10: 0x1005a2c15 v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
11: 0x1005a2c7f v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
12: 0x100571e63 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
13: 0x100805ccc v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/xyz/.nvm/versions/node/v10.20.1/bin/node]
14: 0x3ea875f5be3d 
15: 0x3ea875f5d1ff 
ERR! => Failed to build the preview
ERR! vendors~main.32009e1438c5ef1ca75d.bundle.js from Terser
ERR! Error: Call retries were exceeded
ERR!     at ChildProcessWorker.initialize (/Users/xyz/Projects/a-dir/node_modules/@storybook/core/node_modules/jest-worker/build/workers/ChildProcessWorker.js:230:21)
ERR!     at ChildProcessWorker._onExit (/Users/xyz/Projects/a-dir/node_modules/@storybook/core/node_modules/jest-worker/build/workers/ChildProcessWorker.js:307:12)
ERR!     at ChildProcess.emit (events.js:198:13)
ERR!     at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)
(node:14471) UnhandledPromiseRejectionWarning: [object Object]
(node:14471) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:14471) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed.
Exit code: 1
Command: /Users/xyz/.nvm/versions/node/v10.20.1/bin/node
Arguments: /usr/local/Cellar/yarn/1.22.4/libexec/lib/cli.js run build-storybook
Directory: /Users/xyz/Projects/a-dir/bla_de
Output:

To Reproduce run yarn build-storybook

Expected behavior The build shouldn't fail.

Screenshots nothing

Code snippets on request

System: Environment Info:

System: OS: macOS 10.15.4 CPU: (8) x64 Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz Binaries: Node: 10.20.1 - ~/.nvm/versions/node/v10.20.1/bin/node Yarn: 1.22.4 - /usr/local/bin/yarn npm: 6.11.3 - ~/Projects/a-dir/node_modules/.bin/npm Browsers: Chrome: 83.0.4103.61 Firefox: 76.0.1 Safari: 13.1

Framework: React

Additional context I tried the following to solve the problem:

1. delete all node_modules folders and reinstall all packages
2. upgrade storybook to latest version 5.3.19
3. upgrade storybook to version 6 beta 12
4. set the RAM usage of node with npx --max_old_space_size=16384 build-storybook

All of that does not solve the error.

[shilman]

@ndelangen what's the current thinking on terser plugin?

[Tobi-mmt]

The quickfix for me was to use the node version 12.x instead of 10.x . I don't know why, but this solves the problem for me at the moment.

If I switch back to 10, it is still failing 🤷‍♀️

[ndelangen]

@ndelangen what's the current thinking on terser plugin?

It's the best in class javascript minifier AFAIK.

@Tobi-mmt I'm glad you found a work-around.

I'm not sure what to do.. Well code splitting will possibly help.

[wkeese]

Hmm, it's failing for me even on Node 12. Getting that same error:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

[ndelangen]

Could you try:

NODE_OPTIONS=--max_old_space_size=4096 build-storybook

or increase the number to more?

[wkeese]

I did try 4096 and it still failed. I tried 8192 and it just never finished. I suppose I should try spliiting things into layers, maybe the polyfills for IE.

[IshratPahalwi]

I too am facing this issue. Any updates ?

[jfoliveira]

Same error here with Storybook v5.3.18 and node v12.18.0. Running on an almost empty 4 GB RAM AWS EC2 instance (only nginx running) dedicated to build Storybook for a ReactJs web app with ~30 components and 5 pages. :-(

Using NODE_OPTIONS as suggested in other comments, the task seems to never finish (I waited for only one hour):

NODE_OPTIONS=--max_old_space_size=4096 yarn build-storybook

Question: Could anyone please guide me on how to tell Storybook to not optimize, not minify, not use source maps, etc?

I went to the Storybook docs on customizing webpack but couldn't even find the words optimize, minify, source maps, and all other keywords that come to my mind.

As I really don't want to become a Webpack expert and I don't need any fancy bundling or any other optimization, I just need to get Storybook to work and be served as a static HTML site. If it's not minified, if it's not bundled but it's working that would be cool and perhaps all I'll ever need.

Please let me know what should I change to serve Storybook the simplest possible way and no longer be stuck at the 92% chunk asset optimization TerserPlugin building stage.

Thanks in advance for any advice!

[IshratPahalwi]

For me this worked : NODE_OPTIONS=--max_old_space_size=4096 build-storybook . However, my travis build seems to give the error : The job exceeded the maximum log length, and has been terminated during the storybook build. I am assuming the storybook build is generating too much logs which is causing the travis build to terminate . Can anyone please suggest how to supress storybook from generating too much unnecessary logs ?

[jfoliveira]

Storybook as a component gallery is an amazing project and then we're here: developers struggling to take the most of this beautiful tool due to bundling size optimization issues - bundling that is not even needed in many scenarios.

Why is bundling such an important thing for a project like Storybook that mainly targets internal audience? A very successful web app with 1 million daily users will share their components in Storybook with all their users? I don't think so.

It's very likely only devs, product owners, managers, designers, UX/UI teams will need to interact with a Storybook instance. How big can an internal team like that be? 500 (five hundred) people in a really big enterprise? And how many of them will be interacting with Storybook from a slow internet connection? I can't say, but it seems to me that will actually be an edge case.

In a scenario with up to 500 Storybook users is all this out-of-the-box optimization really worth it?

Sorry, I'm completely new to this project and don't mean to be critical, just putting this as food for thought. I hope it's taken as some opportunity for improvement rather than as a negative feedback.

[ndelangen]

@jfoliveira would you be interested in voicing your opinion on this matter in our next roadmap meeting?: https://github.com/storybookjs/community

[jfoliveira]

Hey @ndelangen ! Thanks for the invite! Not sure if l'll be able to make it to the roadmap meeting but I'll try to attend.

In the meantime, for those still facing this same issue when building Storybook, I share below the minimal config changes that I came up with on my .storybook/main.js to disable bundling:

module.exports = {
  webpackFinal: async (config, { configType }) => {
    config.optimization = {
      minimize: false,
      minimizer: [],
    };

    return config;
  },
  stories: ['../**/*.stories.js'],
  addons: [
...

After applying these changes the error message 92% chunk asset optimization TerserPlugin no longer appeared. I've built/deployed on the same remote servers a few dozens of times in the past week, successfully.

Some numbers that might be helpful: 1) My web server: I downgraded to an AWS EC2 t2.micro instance as my build server + web server: 1 GB RAM + 1 GB swap disk space.

2) Build time - with bundling off: Build is taking 2 to 3 minutes to complete, which for my team is totally acceptable.

3) Final assets size: main*.bundle.js ~ 11 MB vendor*.bundle.js ~ 2 MB Total page size: 14 MB (according to Firefox 77)

4) Page load time: About 5 minutes to load Storybook on the browser. I know, it's not great - but it's working fine for my team. Also, as I'm serving Storybook as a Node.js app from a very small/cheap cloud server instance, I think it's ok. Load it, go grab a coffee and then it'll be available offline and cached in the browser. :-)

Hope this helps other Storybook users on deciding whether disabling bundling might be an option for them or not.

[ghost]

Maybe to add a little more information. I have the same memory leak issue when running start-storybook.

Storybook Version: 5.3.18 Angular Version: 8.1.2 Node Version: 12.16.1

95% emitting fork-ts-checker-webpack-plugin

[xseman]

start-storybook I can confirm memory leak, storybook consumed about 6GB of RAM.

storybook/react:: v5.3.18 Node: v14.5.0 OS: Linux (Debian 10)

[neil-morrison44]

We've got two (large ish) projects that build storybooks as part of their CI, both started failing with JavaScript heap out of memory errors after @babel/core auto-updated from 7.10.5 to 7.11.0, a 3rd project with a much smaller JS footprint (no react) is fine on v7.11.0 though.

storybook/react:: v5.3.19 Node: v12 OS: Linux (Travis CI Container)

[ndelangen]

@neil-morrison44 If you upgrade to storybook 6.0.0 does this improve for you?

[floppey]

I have the same problem or at least similar to what @neil-morrison44 describes. I'm building a component library/styleguide with lerna + storybook. After adding a package with 85 icons (85 react components and 85 svg files) I'm no longer able to run yarn storybook.

This is the error I get.

yarn storybook
yarn run v1.22.4
$ start-storybook -p 9009 -s public
info @storybook/react v6.0.10
info 
info => Loading static files from: /Users/usr/Projects/DesignSystem/public .
info => Loading presets
info => Loading presets
info => Loading config/preview file in "./.storybook".
info => Loading config/preview file in "./.storybook".
info => Loading custom manager config.
info => Adding stories defined in ".storybook/main.js".
info => Using default Webpack setup.
webpack built a7d5cc59c7a6dd7b2b1d in 29942ms
╭─────────────────────────────────────────────────────╮
│                                                     │
│   Storybook 6.0.10 started                          │
│   25 s for manager and 36 s for preview             │
│                                                     │
│    Local:            http://localhost:9009/         │
│    On your network:  http://192.168.50.136:9009/    │
│                                                     │
╰─────────────────────────────────────────────────────╯

<--- Last few GCs --->

[748:0x102d57000]    91717 ms: Mark-sweep 1946.2 (2067.1) -> 1931.0 (2064.6) MB, 1094.4 / 1.0 ms  (average mu = 0.140, current mu = 0.062) allocation failure scavenge might not succeed
[748:0x102d57000]    91808 ms: Scavenge 1946.0 (2064.6) -> 1933.1 (2065.9) MB, 9.9 / 0.2 ms  (average mu = 0.140, current mu = 0.062) allocation failure 
[748:0x102d57000]    91884 ms: Scavenge 1947.7 (2065.9) -> 1934.9 (2067.4) MB, 9.2 / 0.2 ms  (average mu = 0.140, current mu = 0.062) allocation failure 

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x35486ea808d1 <JSObject>
    0: builtin exit frame: new Date(aka Date)(this=0x354878100591 <the_hole>,0x35484762e8d9 <HeapNumber 1.5967e+12>,0x354878100591 <the_hole>)

    1: ConstructFrame [pc: 0x10095de5a]
    2: new constructor(aka BigIntStats) [0x354824b845d1] [internal/fs/utils.js:~390] [pc=0x31768d432885](this=0x35484762e7b1 <BigIntStats map = 0x3548084ae5b9>,0x35484762e671 <BigInt 16777221>,0x35484762e689 <BigIn...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x1011d1c65 node::Abort() (.cold.1) [/usr/local/bin/node]
 2: 0x10009f919 node::Abort() [/usr/local/bin/node]
 3: 0x10009fa7f node::OnFatalError(char const*, char const*) [/usr/local/bin/node]
 4: 0x1001e3867 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 5: 0x1001e3807 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 6: 0x10036b995 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/bin/node]
 7: 0x10036d20a v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/usr/local/bin/node]
 8: 0x100369c3c v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/bin/node]
 9: 0x100367a3e v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
10: 0x10037390a v8::internal::Heap::AllocateRawWithLightRetry(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
11: 0x100373991 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
12: 0x10034ab2e v8::internal::Factory::NewNumber(double, v8::internal::AllocationType) [/usr/local/bin/node]
13: 0x10054339c v8::internal::JSDate::New(v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Handle<v8::internal::JSReceiver>, double) [/usr/local/bin/node]
14: 0x100263bb0 v8::internal::Builtin_Impl_DateConstructor(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/usr/local/bin/node]
15: 0x1009dcc79 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/usr/local/bin/node]
16: 0x10095de5a Builtins_JSBuiltinsConstructStub [/usr/local/bin/node]
error Command failed with signal "SIGABRT".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Note that I am able to build the static version of the storybook without getting this error.

[ndelangen]

@floppey that's a different issue than the one reported (original is specific to build-storybook).

I can't find anything that explains that behavior... Your storybook starts successfully, and then runs out of memory, creating a new Date ?

[neil-morrison44]

@ndelangen I believe the storybooks which are running out of memory for us when being built are also running out of memory when being built via watch

[floppey]

@ndelangen I tried your earlier tip NODE_OPTIONS=--max_old_space_size=4096 build-storybook and that worked for me, at least for now.

[neil-morrison44]

@ndelangen still getting FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory on 6.0.16 (both building & watching)

NODE_OPTIONS=--max_old_space_size=4096 does get slightly further (56% vs 49%) but it seems like the process gets Killed by something

[ndelangen]

@neil-morrison44 any custom webpack config you can share, that might be the cause? Anything in your codebase you think is noteworthy?

I don't have a lot to go on, to debug this.

[neil-morrison44]

@ndelangen Sure, I'll share what I can

Here's the .storybook/webpack.config.js for one of the projects that's now failing to watch / build, there's some things in there that don't need to be there anymore since we've not had reason to change them for a couple of years

.storybook/webpack.config.js

```js const autoprefixer = require("autoprefixer") module.exports = async ({ config }) => { config.module.rules.push( { test: /node_modules\/[company-prefix]-.*\.jsx?$/, use: [ { loader: "babel-loader", options: { plugins: [ "@babel/plugin-proposal-class-properties", "@babel/plugin-proposal-optional-chaining", "babel-plugin-react-docgen", ["@babel/plugin-proposal-object-rest-spread", { useBuiltIns: true }] ], presets: [ [ "@babel/env", { corejs: 3, modules: false, useBuiltIns: "usage" } ], "@babel/preset-react" ] } } ] }, { test: /\.(sass|s?css)$/, exclude: /node_modules/, use: [ { loader: "style-loader" }, { loader: "css-loader" }, { loader: "postcss-loader", options: { plugins: () => [autoprefixer()] } }, { loader: "sass-loader", options: { sassOptions: { includePaths: [ "node_modules/[component_library_1]/styles", "node_modules/[component_library_2]/styles" ] } } } ] }, { test: /^.*\.(?!s?[ca]ss$|svg|png|[ec]?jsx?$|json$|html?|map$|md$)[^.]+$/, loader: "file-loader" } ) // Return the altered config return config } ```

Other potentially relevant things:

.storybook/addons.js

```js import "@storybook/addon-knobs/register" import "@storybook/addon-actions/register" import "@storybook/addon-backgrounds/register" ```

.storybook/presets.js

```js module.exports = ["@storybook/addon-docs/react/preset"] ```

.storybook/config.js

```js import { addDecorator, addParameters, configure } from "@storybook/react" addParameters({ options: { panelPosition: "right" }, info: { maxPropObjectKeys: 5, maxPropArrayLength: 6 } }) // Needed for Jest testing if (process.env.NODE_ENV === "test") { require("babel-plugin-require-context-hook/register")() } function requireAll(requireContext) { return requireContext.keys().map(requireContext) } function loadStories() { requireAll(require.context("../lib/", true, /.*\.story\.js/)) } configure(loadStories, module) ```

The final storybook (the last one that got built & deployed prior to the heap issue) had 121 .sidebar-items when all expanded, there's probably a better way to count stories but I couldn't find it.

[neil-morrison44]

Noticed something while adjusting my babel config, looks like removing babel-plugin-react-docgen got the build working again, not sure what to make of that though

The stacktrace before it was removed:

Stack Trace

``` 51% building 343/404 modules 61 active /user/node_modules/core-js/internals/new-promise-capability.js <--- Last few GCs ---> [556:0x3944a70] 62328 ms: Scavenge 987.7 (995.2) -> 986.9 (995.2) MB, 4.5 / 0.0 ms (average mu = 0.083, current mu = 0.036) allocation failure [556:0x3944a70] 62337 ms: Scavenge 988.0 (995.2) -> 987.4 (996.7) MB, 6.2 / 0.1 ms (average mu = 0.083, current mu = 0.036) allocation failure [556:0x3944a70] 62346 ms: Scavenge 989.2 (996.7) -> 988.4 (1001.9) MB, 5.8 / 0.1 ms (average mu = 0.083, current mu = 0.036) allocation failure <--- JS stacktrace ---> ==== JS stack trace ========================================= 0: ExitFrame [pc: 0x13a71b9] Security context: 0x26729fa008d1 1: hasOwnProperty [0x26729fa02bd1](this=0x3017fa889409

[bismarkhenao]

I was digging on this error, and what I found was that I was using this PropTypes.arrayOf() on one of my components, after change it to PropTypes.arrayOf([]) it worked again. 😕

[zeropaper]

@bismarkhenao did the same mistake (PropTypes.arrayOf() without values), had the same OOM and it got fixed once I corrected arrayOf usage. Thanks for the hint, I could have search elsewhere for a while. In other words, for me the problem wasn't storybook but my lack of focus :D

[SamKirkland]

Hey everyone.

I had the same problem with our build: Node: v10.15.3 Storybook: v5.3.18 (A bit old, so might not work for everyone) Error occurred on the following step: 93% ...set optimization ...MapDevToolPlugin ...23e40.bundle.js generate SourceMap

It looks like TerserPlugin has some problems handling ridiculously large files. In my case we only had 2 js bundles for all of our stories (hundreds). One js file was over 60MB, the other over 20MB. When storybook passed these files to TerserPlugin it couldn't produce the sourcemaps for them, even with 6GB of memory 😮.

The solution for us is as follows.

// storybook main.js
const BundleAnalyzerPlugin = require("webpack-bundle-analyzer").BundleAnalyzerPlugin;

module.exports = {  
    stories: ["src/**/*.stories.(tsx|mdx)"],
    addons: [
        // ...
    ],
    webpackFinal: async (config, { configType }) => {
        // analyze webpack bundle size. To enable run storybook with `cross-env analyze=true`
        // not needed, but helps debug the problem :)
        const shouldAnalyze = process.env.analyze === "true";
        if (shouldAnalyze) {
            config.plugins.push(
                new BundleAnalyzerPlugin()
            );
        }

        // split into more chunks
        config.optimization = {
            splitChunks: {
                chunks: "all",
                minSize: 30 * 1024, // 30KB
                maxSize: 1024 * 1024, // 1MB
            }
        };

        return config;
    }
};

This also allows you to run storybook with cross-env analyze=true to see your bundles after webpack has run. In order to run this you will need to increase your memory size, in the example below I have 2GB set but you might need 8GB or more.

Once the analyzer is done it will open a webpage, if you see bundles larger than a few MB you might want to try this fix out.

// package.json
"scripts: {
    "storybook": "cross-env NODE_OPTIONS='--max-old-space-size=2048' start-storybook",
    "storybook-analyze": "cross-env analyze=true npm run storybook"
}

[mikecann]

@SamKirkland cheers!

I can confirm that this worked for us on v5.3.14

[SyedUmerHasan]

Is there any update on this issue?

[Warkanlock]

I was digging on this error, and what I found was that I was using this PropTypes.arrayOf() on one of my components, after change it to PropTypes.arrayOf([]) it worked again.

wtf, this worked for me...

[nuzzesick]

I was digging on this error, and what I found was that I was using this PropTypes.arrayOf() on one of my components, after change it to PropTypes.arrayOf([]) it worked again. 😕

incredible, this actually works!!

[jw-miaem]

I have experienced stuck TerserPlugin at 92% breaking CI on storybook build latest version (6.3.2). Setting minimizer to false solved it but suggest it needs attention

[reno1979]

Same problem here (6.3.8) stuck TerserPlugin at 92%

[maxgfr]

Problem solved with this version : https://github.com/storybookjs/storybook/releases/tag/v6.3.11

[aperkaz]

Updating to 6.4.8 fixed the issue for me.

[petitkriket]

updating storybook to latest with npx sb upgrade fixed it too, wasted a couple of hours playing with my container settings though 🤣

[Eyad-A]

I'm dealing with the same problem. Running NODE_OPTIONS=--max_old_space_size=4096 yarn storybook bypasses this error and storybook launches successfully. However, as soon as I click anything in storybook, I get maximum call stack size exceeded error.

[Robin-Hoodie]

Problem solved with this version : https://github.com/storybookjs/storybook/releases/tag/v6.3.11

This error is still popping up for me using version 6.5.12

[IceDevelop74]

Problem solved with this version : https://github.com/storybookjs/storybook/releases/tag/v6.3.11

This error is still popping up for me using version 6.5.12

Same in 6.5.15. Any update on this?

[ndelangen]

I don't think this is strictly a problem with storybook. Likely the problem lies upstream: TerserPlugin possibly, or simply the problem arises because of too large files.

Here's the known work-around: https://github.com/storybookjs/storybook/issues/6408#issuecomment-722692755

[IceDevelop74]

I don't think this is strictly a problem with storybook. Likely the problem lies upstream: TerserPlugin possibly, or simply the problem arises because of too large files.

Here's the known work-around: #6408 (comment)

I've tried this workaround but nothing changes :/

[pcambra]

I've tried the workaround above and disabling the source maps and I have this issue in 7.0.7

[dizzyjaguar]

Currently also having this issue in 7.0.7

[mayerraphael]

Same here. 7.0.7

[chad-levesque]

Same error, 7.0.10. Running out of memory on Gitlab runner with source maps disabled and NODE_OPTIONS: '--max-old-space-size=4096' Not sure what to try next 🤔

[catnuko]

Same 7.0.8

[ndelangen]

Does someone have a repro I could use for an experiment?

I wonder if replacing Terser with esbuild would fix this problem.