storybookjs / storybook

Storybook is the industry standard workshop for building, documenting, and testing UI components in isolation
https://storybook.js.org
MIT License
83.86k stars 9.18k forks source link

Javascript heap out of memory when doing build-storybook #6408

Open yuanstanley opened 5 years ago

yuanstanley commented 5 years ago

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:

maxphillipsdev commented 1 year ago

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

rajpawar02 commented 1 year ago

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

ndelangen commented 1 year ago

@maxphillipsdev @rajpawar02

Would you mind giving this a try:? https://github.com/storybookjs/storybook/blob/3bc12db08bb7788dc3263bb59c468a0c1fe68313/docs/snippets/common/main-config-framework-options-builder-use-swc.js.mdx#L1-L16

vui611 commented 1 year ago

@ndelangen give it a go but still got the out-of-memory problem. VM has 4Gb memory and the storybook is v7.0.24

sachin-walunj commented 1 year ago

@maxphillipsdev @rajpawar02

Would you mind giving this a try:?

https://github.com/storybookjs/storybook/blob/3bc12db08bb7788dc3263bb59c468a0c1fe68313/docs/snippets/common/main-config-framework-options-builder-use-swc.js.mdx#L1-L16

Tried this solution but still facing the same issue

sachin-walunj commented 1 year ago

Screenshot 2023-07-07 at 12 58 26 PM

dimafirsov commented 1 year ago

@maxphillipsdev @rajpawar02

Would you mind giving this a try:?

https://github.com/storybookjs/storybook/blob/3bc12db08bb7788dc3263bb59c468a0c1fe68313/docs/snippets/common/main-config-framework-options-builder-use-swc.js.mdx#L1-L16

Thanks @ndelangen, looks like this fixed the memory leak issue for the vite builder with the mentioned above memory boost NODE_OPTIONS=--max_old_space_size=9126.

storybook 7.0.25

juanigalan91 commented 1 year ago

👋 I can reproduce with our repo using storybook 7.1.0.

In my end, removing the feature storyStoreV7 fixed the issue and allowed the build to finish. I've narrowed the issue to TerserPlugin not being able to handle so many files, specifically files that weight a lot (around 10MB).

    features: {
        storyStoreV7: false,
    },

I've tried to tweak TerserPlugin by removing either parallel building, or just removing comments without minification but I had no success.

My best guess is that storyStoreV7, which enables code splitting (per storybook's documentation), and then splits stories into multiple bundles, therefore generating a main.bundle with all the common code used across all stories. This file has so much code (at least in our scenario) that TerserPlugin is not able to handle the size and runs out of memory.

ndelangen commented 1 year ago

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

juanigalan91 commented 1 year ago

hi @ndelangen thanks for the tip!

Unfortunately I am still running out of memory. I've also tried using TerserWebpackPlugin .esbuildMinify and TerserWebpackPlugin .uglifyJsMinify by modifying the webpack configuration manually, but I had unfortunately the exact same result.

The only workaround that I've managed to find while keeping storyStoreV7: true is to add NODE_OPTIONS=--max-old-space-size=4096 to the build script. But I must admit, it feels like cheating 😅

ndelangen commented 1 year ago

FYI storyStoreV7: false will be removed/unsupported in the future (8.0 likely)

juanigalan91 commented 1 year ago

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.

lordrip commented 11 months ago

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/

Silinator commented 9 months ago

Same issue now on 7.5.3 on github actions and only some times also in CLI With "build-storybook": "NODE_OPTIONS=--max_old_space_size=4096 storybook build" It's worked for me.

But kind of strange why i have to this < 7.5.3 worked for me with out any problems and i only have 4 Stories at the moment.

williamhaley commented 7 months ago

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

johndpotts commented 3 weeks ago

another workaround for this is setting minimize: false on your webpack optimization config, as mentioned here: https://github.com/storybookjs/storybook/issues/20716

Walnussbaer commented 6 days ago

EDIT: probably related to https://github.com/storybookjs/storybook/pull/28589

Since our upgrade to Storybook 8.2.9, we also get this error when trying to build storybook for production deployment (dev server works just fine)

info => Loading presets
info => Building manager..
info => Manager built (218 ms)
info => Building preview..
info => Copying static files: public\assets at storybook-static\assets
vite v5.3.5 building for production...
info => Copying static files: src\assets\fonts at storybook-static\assets\fonts
transforming (43) node_modules\@vue\compiler-dom\dist\compiler-dom.esm-bundler.jsinfo => Copying static files: src\assets\animations\lottie at storybook-static\assets\animations\lottie
transforming (347) node_modules\quasar\src\css\index.sass
<--- Last few GCs --->

[301032:000001F029C61750]    93893 ms: Scavenge (reduce) 3786.0 (3867.5) -> 3785.1 (3867.5) MB, 9.7 / 0.0 ms  (average mu = 0.981, current mu = 0.974) allocation failure;
[301032:000001F029C61750]    95150 ms: Mark-sweep (reduce) 4748.2 (4830.0) -> 4714.7 (4827.2) MB, 42.1 / 0.5 ms  (+ 289.7 ms in 3656 steps since start of marking, biggest step 0.3 ms, walltime since start of marking 4239 ms) (average mu = 0.977, current m

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 00007FF72394D51F node_api_throw_syntax_error+175743
 2: 00007FF7238D2E66 v8::internal::wasm::WasmCode::safepoint_table_offset+59654
 3: 00007FF7238D4B72 v8::internal::wasm::WasmCode::safepoint_table_offset+67090
 4: 00007FF72437AAB4 v8::Isolate::ReportExternalAllocationLimitReached+116
 5: 00007FF724365E12 v8::Isolate::Exit+674
 6: 00007FF7241E7C6C v8::internal::EmbedderStackStateScope::ExplicitScopeForTesting+124
 7: 00007FF7241E4E8B v8::internal::Heap::CollectGarbage+3963
 8: 00007FF7241ECAE5 v8::internal::Heap::GlobalSizeOfObjects+341
 9: 00007FF72423C14F v8::internal::StackGuard::HandleInterrupts+863
10: 00007FF723EFD826 v8::internal::DateCache::Weekday+6886
11: 00007FF724418051 v8::internal::SetupIsolateDelegate::SetupHeap+558193
12: 00007FF7243CBA37 v8::internal::SetupIsolateDelegate::SetupHeap+245335
13: 00007FF7243E8CA2 v8::internal::SetupIsolateDelegate::SetupHeap+364738
14: 00007FF7243974DA v8::internal::SetupIsolateDelegate::SetupHeap+30970
15: 00007FF6A4D97113