storybook: Javascript heap out of memory when doing build-storybook

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

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.

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. 😕

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.

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® Core™ 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.

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!

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"
}

Could you try:

NODE_OPTIONS=--max_old_space_size=4096 build-storybook

or increase the number to more?

Currently also having this issue in 7.0.7

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?

@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 😄

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

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

Is there any update on this issue?

Thanks for following up @yuanstanley – glad it’s working for you!

same result in 7.0.22. Tried running with 4GB on aws amplify but no luck

same result in 7.0.22. Tried running with 4GB but no luck

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.

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

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

Same issue here on a 4GB self-hosted runner on Github Actions. Killed with status 137 (OOM) seemingly at random on some jobs. Using the @storybook/nextjs framework as this is a Next.js project. Using version 7.6.10 for storybook and related @storybook/... addons.

<s> [webpack.Progress] 92% sealing asset processing TerserPlugin
Killed
error Command failed with exit code 137.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed.
Exit code: 137
Command: /opt/hostedtoolcache/node/18.19.0/x64/bin/node
Arguments: /opt/hostedtoolcache/node/18.19.0/x64/lib/node_modules/yarn/lib/cli.js build
Directory: /runner/_work/mugen/mugen/packages/storybook
Output:

Other jobs in the same workflow like tests, docker builds, deployments, compilation, etc., are all fine on that same runner so I’d rather not bump up to a larger one just for the sake of getting Storybook to build.

Changing the framework as suggested here seemed to yield reliable builds for the time being at least 🤞

edit: unfortunately, swc means I no longer use babel, which means I can’t use idInterpolationPattern for format js, and so I had to turn off useSwc again 🥀 https://github.com/storybookjs/storybook/discussions/25772

In my case, I had a few big files.

storybook-static/assets/Catalog.stories-9eab6292.js                  9,958.00 kB │ gzip: 1,228.47 kB │ map:   160.12 kB

Locally, it worked for me, so the failure only happened on GitHub actions nodes. To replicate the issue, I modified the command as follows:

    "build:storybook": "NODE_OPTIONS=--max_old_space_size=2048 storybook build",

The fix for me was to reduce a JSON file used for providing demo data for one of the stories and then the files got smaller.

storybook-static/assets/Catalog.stories-ac6ca80f.js                  2,538.06 kB │ gzip: 313.20 kB │ map:   159.61 kB

In any case, @ndelangen , here’s our repository if you want a reproduction example: https://github.com/KaotoIO/kaoto-next/

Hope this gets fixed or at least we have a workaround for it by then. I feel like the code splitting might be a bit too agressive with storyStoreV7: false and it is not providing us the best results when it comes to building storybook and deploying it. At least that is what I understand from what is going on.

Maybe we would need to split our monorepo’s storybook into sub storybooks and unify all of them with storybook composition, but it feels like a regression.

@juanigalan91 maybe this is something you might want to try: https://github.com/storybookjs/storybook/blob/868120a59e1985c834791cf72f467bc6251d5f13/docs/snippets/common/main-config-framework-options-builder-use-swc.js.mdx#L1-L16

It’s an experimental option to switch from babel to swc, and will also switch to TerserWebpackPlugin.swcMinify.

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

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

Same 7.0.8

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

I too am facing this issue. Any updates ?

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.

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 🤷‍♀️